weekly 259-260-261-262 – July


Campuskarte mit 3d BuildingsCampus with 3D Buildings [1]

About us

  • Since issue #262, Marc Gemis from Belgium has joined the German Wochennotiz team and adds news from Belgium and from the French community.
  • We are also happy to announce that Ruben Lopez Mendoza from Ayacucho, Peru has joined the Spanish weeklyOSM team. Bienvenido Ruben!


  • OSM may continue to use Bing imagery even after the takeover by Uber.
  • SK53 asks on twitter how to tag this new electricity tower design.
  • Martijn van Exel announces a Maproulette challenge about missing railroad crossings in the USA.
  • Mapbox published the internal OSM mapping instructions that are used by their data team.
  • Yandex (a Russian search engine with a map portal) now offers a Street View service. The images (not the map and aerial photographs) may be used for mapping. (automatic translation)
  • OpenHistoricalMap builds maps on its own infrastructure using OSM tools. (via @GuerrillaCarto)
  • On GitHub it has been possible for some time to represent a GeoJSON file via an OSM Layer (example). Now a link to the MapBox “Improve this map” feature has been added to help resolve (via iD or OSM Notes) any map errors.
  • On the talk-fr list there has been a discussion about the border between France and Italy in the Mont Blanc area. This was followed by a discussion on the tagging list about how to map border disputes.
  • Marc Zoutendijk explains how you can find strange tagged POIs with the OpenPOIMap. To do this click in the top right corner of OpenPOIMap “User POIs” and use a query e.g. amenity=shop.
  • In a twelve-part series, Tlatet analysed the quality of POIs in OSM (specifically retail in England).
  • Andreas Weber and Dennis Nienhüser (FZI Karlsruhe) have created a system for use with a Segway that recognises traffic signs so that they can be uploaded it to OSM (Video).



OpenStreetMap Foundation

  • The draft minutes of OSMF´s board meeting as of 2015-06-15 is now available in the OSMF-Wiki.
  • On July 20 the first public OSMF board meeting was held. The minutes and an audio recording of the meeting will follow soon.

Humanitarian OSM


  • Users ccalista explains in her blog how current OSM data can be loaded into OsmAnd via Overpass to test the most recent changes with OsmAnd.
  • Andy Allan proposes (in an issue of the OSM Carto project) to introduce a directive to decide what new features are to be included in the rendering of the main style on osm.org and which are not.
  • Adrien Pavie published OpenLevelUp!, an online map for watching objects in the specific floors of indoor-mapped buildings
  • The Austrian “Der Standard” reported on the company Pentamap, a spin-off from the Geodetic Institute of the Technical University of Graz. The company works on an off-road routing in the Alps for mountain rescuers and hunters using aerial photography and digital terrain models and OSM data. (automatic translation)
  • [1] The University of Leicester has created a map of the campus based on OSM data and OSM Buildings. (via @GISPowered)
  • The GPSies website hasbeen redesigned. See the blog post here.
  • Mateusz Konieczny presents a new default map style version and asks for feedback (see other diary entries for previous posts on the same topic).
  • On the British OSM mailing list, one topic is a suggestion for a rendering style specifically for the UK.
  • Omar Ureta visualised OSM-based tiles with Stamen-Watercolour style with terrain elevation data of the regional administration.


  • The Vehrkehrsmanagementzentrale (traffic management center) of Lower Saxony published a new website. There are shown traffic jams and construction sites all over Germany. The map display on Tablet and Desktop uses OSM maps.


  • The Austrian Federal Office of Metrology and Surveying (Bundesamt für Eich- und Vermessungswesen, BEV Österreich) has published all address details with pinpoint accuracy. Thomas Ruprecht is in contact with the BEV, to allow the use of these data and the administrative boundaries for OSM.
  • The Belgian Council of Ministers adopted a new open data strategy. Basically, all the records are to be published from 2020 under CC0 license.


  • As the main client of MapDB has withdrawn, Jan Kotek is looking for new sponsors for the project.
  • Michael Zangl presents the first release of its OpenGL MapView of JOSM, (part of the Google Summer of Code).
  • Do you or your company want to sponsor a new QGIS-Feature?
  • Developer Dennis Nienhüser has released a new Version 1.11.3 of Marble for Windows.
  • The Geometalab of the University of Rapperswil is working on an extract-tool for OSM data for various formats: GeoPackage, Shapefile, FileGeodatabase and Garmin (.img).
  • Version 1.1.1 of the iOS-Port of OsmAnd was released.
  • The OSM-based and open source Geo Search Engine Photon now also supports “Reverse Geocoding”, i.e. output of address to a transferred X / Y coordinate.
  • User Amaroussi asks on Twitter, how to deal with the imminent end of Flash in respect of Potlatch. Luckily in the future there will still be ID, Level0, Merkaartor, JOSM, Vespucci and, er, Potlatch!.
  • NGA and DigitalGlobe have jointly published Hootenanny. A free and open project to facilitate the handling of large amounts of spatial data. (via un-spider)
  • MapBox published a first release of a minimalist C ++ 11 protobuf de- and encoder. (via @springmeyer)
  • Mapbox has created a node.js and browser Javascript client for Mapbox services (geolocation, routing, etc.). (via @tmcw)
  • The backend code of the OSRM project can now be compiled under Windows as a DLL. (via @tdihp)
  • Omniscale published a tool called Magnacarto, which can convert map styles from CartoCSS format into Mapnik XML or MapServer mapfile.

Did you know …

  • … about the 3D rendering from F4Map?

Other “geo” things

A Task for the Summer Holidays—Guideposts along Hiking Routes

A typical hiking guidepost in the Austrian alps

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

For the German community it has become a habit to do so-called “tasks of the week”—a common mapping effort with a specific topic like turning lanes or pharmacies. This time we are going one step further—a task for the summer holidays. Mapping guideposts along hiking or bicycle routes. Due to its inherent complexity—guideposts are usually spread over a large area and are not as easy accessible as other objects, the task was divided in two parts. First, mappers are asked to take pictures of guideposts during their summer holidays—a time that many people spend doing hiking or biking tours with their families. The actual mapping of the surveyed information will take place in early September, when people are back home. To refer to this task in blog posts and changeset comments the hash tag #OSMWA1536 can be used.

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 (in German forum as well). 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-levelled 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.