dhcpd.conf – nicer formatting

Keeping an eye on all those entries in a DHCP servers configuration file is a bit tedious. On the other hand, it’s not worrisome enough to use any graphical interface to edit it. One thing I dislike most is the typical format of each entry, that is

host devicename {
      hardware ethernet 12:34:56:78:90:ab;

I prefer a clean, sorted list, like:

host devicename  {hardware ethernet 12:34:56:78:90:ab;   fixed-address; }
host devicename2 {hardware ethernet 12:34:56:78:90:ac;   fixed-address; }

Hence, I wrote a script that reads a typical dhcpd.conf file and

  • Outputs all host lines in single-line format
  • Sorts entries by IP
  • Groups entries by /24 subnet

The source code is available on my github: dhcpdformatter

Veröffentlicht unter Tools

Bookmarklets für OSM

Mal schnell ein Changeset in Achavi anschauen? Oder einen Key bei Taginfo nachschlagen?
Einfach die Links als Bookmark in der Toolbar speichern, einen Text auf irgendeiner Webseite markieren und den passenden Bookmark aufrufen!

Diese Links sollten in fast jedem aktuellen Browser funktionieren, nur der Internet Explorer könnte Schwierigkeiten machen…

Veröffentlicht unter OSM

Remote Presenter

Having discussions on presentation slides via phone? Having round-table meetings where everybody wants to show his one own slide? Then you might know some of the following scenarios:

  • „How can I show you the slides“ – „Oh, send them by mail.“ – „Have they arrived yet?“ – „Which slide are you viewing right now?“ – „Page 23 or Slide 23? Or the one labelled ’23‘?“
  • „Could you pass me the VGA cable for the projector?“ – „How do I make this computer show the image?“ – „Maybe I can show my slide first?“ – „Why doesn’t it work with my adapter? Is the projector broken?“

I wrote a tiny tool that can handle these situations – A webpage where you can upload your PDF or images, and everybody connected sees the same slides, can select slides for a ‚private‘ view, select slides to show to everybody else. Works with ‚any‘ web browser, no special tools required on the users‘ end. E.g. open the website on the main presentation PC, and all people in the meeting can control slides using their mobile devices.

As usual, the code can be found on github: https://github.com/mueschel/RemotePresenter. Just 15 kByte of code that might save a lot of time during meetings.

Herbst III

Am 21. September war 2012 in einer eher nördlich gelegenen Universitätsstadt hingegen noch nichts vom Herbst zu spüren. Nur ein wenig Nieselregen zauberte ein Glitzern auf die Steine:

Veröffentlicht unter Foto

Herbst II

Genau ein Jahr später, am 03.10.2014, ein ganzes Stück weiter nördlich, aber wieder in einer bekannten Großstadt:


Veröffentlicht unter Foto


In welcher europäischen Hauptstadt wurde dieses Bild wohl aufgenommen? Es war am 28.09.2013, gegen 12 Uhr und es war warm…

Veröffentlicht unter Foto

LCD Lib portiert für Arduino

Meine LCD-Library ist nun auch kompatibel mit Arduino und lässt sich einfach in jedem Arduino-Sketch benutzen.

Warum das? Damit lassen sich Displays jetzt auch mit einem ESP8266-Modul betreiben und mit den vorhandenen Arduino-Code-Beispielen einfach mit WLAN verheiraten, z.B. mit einem kleinen Telnet-Server ließe sich das Display so remote mit Daten füttern.

Der Code findet sich wie üblich auf github: https://github.com/mueschel/lcdlib-arduino

Guideposts and Destination Signs in OSM

A typical hiking guidepost in the Austrian Alps and its node in the OSM database

How a guidepost can be mapped and which level of detail is desired has been the topic of a thread in the German forum and a dedicated poll (not available any more). The outcome of both discussions was that people have very different opinion on how mapping should be done. Fortunately, there is no conflict between the different options, they merely represent different levels of complexity.

Besides the personal interests of each mapper, the location and type of the sign plays a role when deciding on a mapping scheme. Some guidepost just point to the next locality along a path which is already fully mapped—the additional information by adding these destinations to OSM is marginal at best and can be skipped. The same holds for guideposts along an existing hiking route. In this case, the guidepost itself can be added to the OSM relation and it’s content doesn’t need to be mapped. In other regions, the pure existence of a mapped guidepost is valuable information—e.g. if ways have not been fully traced, the map user could be told to take a way that doesn’t even exist on his map yet.

These considerations led to a three-leveled recommendation how to map guideposts:

Level 1—The Guidepost

Each and every guidepost found should exist in OSM as a node tagged tourism=information and information=guidepost. Following additional tags that can be used:

  • hiking=yes / bicycle=yes — is the guidepost designated to a specific group of users?
  • operator=* — the organization responsible for the guidepost
  • ref=* — some operators use reference numbers on their signs
  • material=* — the material the guidepost is made of, e.g. wood or metal
  • colour=* — the color of the guidepost

If someone does not want to map destinations, the content of the signs might be made visible to other mappers or map users by either adding a url tag pointing to the image taken or the text of the signpost can be put into a note:destination or inscription tag.
In case the guidepost is part of an existing hiking route relation, it should be added to it. Further mapping of destinations is not required in this case.

Level 2—Destinations as Keys on a Way

On most highways destinations are mapped using the destination=* and its sub-keys including the :forward/:backward suffixes. This scheme can be used on hiking routes as well. The tags are put on a way in OSM starting or ending near the actual guidepost. Useful keys are

  • destination=* — Give the destinations as a list, separated by semicolon.
  • destination:symbol=* — in case a symbol is shown (usually for amenities like restaurants)
  • destination:ref=* — the reference number of another way the guidepost points to
  • destination:lang:XX=* — some destinations might be posted in several languages. Use the common language keys in place of „XX“

Please note that the addition of :forward or :backward is necessary in most cases – the destination given is only valid when travelling the way in one direction but not in the other. The suffix is always added to the very end of the key.

Level 3—Destinations as Relations

The most precise though time consuming option is to use relations of type destination_sign. A destination sign relation has three members. The guidepost (using role sign), the intersection node on the way (role intersection) and the way the sign points to (to). Besides its type, the relation takes the keys mentioned above and in addition:

  • distance=* — the distance to the listed destination as shown on the sign. Default unit are kilometers, others can be used but need to be specified (e.g. 6.5 miles, 550 m)
  • time=* — The time to destination indicated on the sign. The format is „HH:MM“, giving both hours and minutes.
  • colour:back=*, colour:text=*, colour:arrow=* — the colors used on the sign


Some general remarks about tagging: Always choose the most appropriate scheme—none is better or worse. Keep the tagging as simple as possible without losing too much information. Trivial information does not need to be mapped.

[This text also appeared on http://www.weeklyosm.eu/archives/4504 in 2015, thanks to Nakaner and Manfred for proof-reading]

Veröffentlicht unter OSM