RSS Feed icon


OSM Inspector touch-up

1.07.2022 | Frederik Ramm

We have made a few small improvements to the OSM Inspector user interface, providing better responsiveness to different display sizes, using tiled WMS access for better performance, and improving the presentation of feature detail information.

Give it a spin at and tell us what you think!

In the past night, a problem on the download server caused us to publish truncated data extracts for the following countries:

In Africa:

  • Benin
  • Cameroon
  • Chad
  • Comores
  • Kenya
  • Mali
  • Mauritius
  • Namibia
  • Niger
  • Nigeria
  • Saint Helena/Ascension/Tristan da Cunha
  • Sao Tome and Principe
  • Senegal
  • Seychelles
  • Swaziland
  • Togo
  • Zambia
  • Zimbabwe

In Asia:

  • Bangladesh
  • Cambodia
  • China
  • India
  • Indonesia
  • Iran
  • Iraq
  • Malaysia
  • Maldives
  • Nepal
  • North Korea
  • Philippines
  • South Korea
  • Sri Lanka
  • Syria
  • Taiwan
  • Vietnam

The extracts have been reset to yesterday’s version but if you have downloaded an extract between 2021-09-05 01:00 UTC and 2021-09-05 10:00 UTC then you have got a truncated file. Also, if you have an automatic process that loads daily updates, and you have loaded and processed an update for any of these countries in that timespan, you now have a truncated database and need to re-import data. (This will not automatically fix itself with the next update.)

If you have not loaded updates during this timespan, or if you have loaded updates but not for the countries mentioned, then you are not affected. (You are also not affected if you have used the full Africa or Asia files, these were correct.)

In the last couple of weeks there have been two events that may have caused tile (or Nominatim) servers to stop updating. Here’s a quick outline on how to identify and repair the problems.
More …

Rework of the OSM Inspector Routing View

14.06.2019 | Michael Reichert

Screenshot of the OSM Inspector Routing view around Landau/Pfalz, Germany

We recently rewrote the OSM Inspector Routing View. The old views were used quite a lot by mappers to find potential routing errors. Unfortunately, they made use of PostGIS to find nearby, unconnected roads which meant having to import the whole road network into a PostGIS database every day. To make matters worse, the island and duplicate segment detection was implemented using OSRM which also has relatively heavy system requirements, especially if you do not limit yourself to automobile routing. This made us have a closer look at using GraphHopper to generate the routing view.

The new backend code was implemented from scratch and does not aim to be a one-by-one reimplementation. It uses GraphHopper to read the planet, build up the graph, analyse it and find nearby edges. Our code uses a forked version of GraphHopper 0.12 with the following changes:

  • The original GraphHopper lacks some callback functions in its OSMReader class. Our changes allow us to build additional indexes and populate maps mapping from internal edge or node IDs to OSM object IDs.
  • The PrepareRoutingSubnetworks class which removes islands from the graph is not extensible but we need to write the edges being removed to a GeoJSON file.

In addition to forking, we implemented a new routing profile (“flag encoder” in GraphHopper speak) accepting any road and ignoring access restrictions. It is used to find duplicated edges, unconnected roads, and islands.

The backend code is available on GitHub.

The new routing view has the following groups of layers:

Duplicated Edges

These layers show edges which exist twice in the graph. The blue ones are almost always real errors and should be fixed by comparing the tags and history of both ways. The purple ones are locations where two edges have equal geometry and at least one of them is an area. Opinions whether areas should share nodes with neighbouring roads are diverse among the OSM community. Therefore, these cases are shown in a separate layer at high zoom levels only.

The results of the duplicated edges layer (not involving areas) are similar to those of OSRM. Minor differences are possible where OSRM excluded a road due to access restrictions while our new implementation includes it.


Screenshot of the OSM Inspector Routing view in Normal, Illinois, US
The use of GraphHopper allows us to identify routing islands for multiple types of vehicles in one go. The OSM Inspector now provides islands for cars and bicycles using slightly modified version of the original profiles of GraphHopper (we use fewer bits to store the speed because island detection does not take travel times or distances into account). In addition, a layer with islands inaccessible to any vehicle is provided. This layer contains fewer entries in total but those contained are more serious because they are not caused by correct or incorrect access restriction tagging in OSM.

Unconnected Nodes

Most development time was spent finding a set of unconnected nodes layers with a proper separation of very likely, likely, potential errors and likely false positives. We are grateful to the folks on the German OSM forum who pointed out many bugs and too high rates of false positives.

Nodes where a single edge ends but with other edges within 15 meters are assigned to one of 6 priority classes. A distance below 2 meters makes a unconnected node appear in the top layer. The further composition of the layers depends on the road class, the distance, and access restrictions. The priority of unconnected nodes involving private access roads is reduced by 1. Service roads and footpaths get low default levels. In addition, the following rules avoid too many false positives:

  • noexit=yes and entrance=* make unconnected nodes disappear.
  • Nearby edges on different layers/levels are ignored.
  • Linear barriers (fences, walls, embankments) are taken into account.
  • Unconnected open ends of parking aisles are ignored if they snap to a parallel edge.
  • If the distance between the open end node and its snap point on the graph is less than twice as long as the beeline distance, no point is shown.

The “snap points” layer shows the snap points of open ends helping to understand the situation.

Not all entries in the unconnected nodes layers are mistakes. Often, adding a linear barrier is helpful. The more blueish a point is, the less likely it is a mistake at all. Don’t feel forced to add noexit=yes to every point the OSM Inspector complains about. You are not mapping for the validator ­čśë

16. OpenStreetMap-Hackweekend in Karlsruhe

23.10.2018 | Christine Karch

Seit 2012 veranstalten wir zweimal bis dreimal im Jahr ein OpenStreetMap-Hackweekend in unseren B├╝ror├Ąumen.

Es wird am Freitag mit einem gem├╝tlichen Abend in der Kneipe eingeleitet. Im Laufe des Abends trudeln die meisten G├Ąste ein. Viele haben eine weite Anreise hinter sich. Sie kommen aus allen Teilen Deutschlands, und oft ist auch der ein oder andere Gast aus dem Ausland dabei.

Von Samstag fr├╝h bis Sonntag abend geht es dann zur Sache. Es wird diskutiert, manchmal auch Flipcharts und Whiteboards vollgeschrieben. Dann wieder ist alles still, weil alle auf ihre Arbeit am Notebook konzentriert sind. Dazwischen unterbrechen wir unsere G├Ąste mit Pizza, Keksen, Gummib├Ąrchen oder Kaffee. Auch den Samstag Abend verbringen wir gemeinsam im Restaurant.

Aufgrund der Routine, die sich im Lauf der Jahre eingestellt hat, mussten wir dieser Veranstaltung zuletzt nur noch sehr wenig Aufmerksamkeit in der Vor- und Nachbereitung schenken. Die Wiki-Seite ist in zwei Minuten aufgesetzt (Copy und Paste vom letzten Jahr, die Termine werden angeglichen, die alten Teilnehmernamen werden quasi nur pro forma herausgel├Âscht). Wir recyclen sogar den alten Einkaufszettel.

Doch unser 16. Hackweekend stellte alles auf den Kopf. Ein zu Martin Raifer leicht dahingesagtes “wir k├Ânnen uns ja auf dem n├Ąchsten Hackweekend dar├╝ber unterhalten” verursachte ein 9-k├Âpfiges Vorbereitungstreffen f├╝r die SotM in Heidelberg im n├Ąchsten Jahr. Und meine Bem├╝hungen, den Austausch mit den Franzosen zu intensivieren, hatte Fr├╝chte getragen. Vincent Privat (aus Toulouse) machte Werbung auf der JOSM-dev-Liste. Sieben JOSM-Entwickler aus ganz Europa (von ├ľsterreich, ├╝ber Polen und Belgien bis Frankreich) meldeten sich an.

Teilnehmer des OSM-Hackweekend Karlsruhe 2018 (Teil 1)

Pl├Âtzlich war klar, dass die angemeldeten 32 G├Ąste ├╝berhaupt nicht in unser B├╝ro passen w├╝rden. Gl├╝cklicherweise hat uns Prof. Dr. G├╝nther-Dieringer ganz kurzfristig und unkompliziert einen Raum in der Hochschule Karlsruhe (University of Applied Sciences) vermittelt. Hierf├╝r danken wir ihm alle ganz herzlich.

Teilnehmer des OSM-Hackweekend Karlsruhe 2018 (Teil 2)

Am Ende war das Hackweekend wieder ein gro├čer Erfolg. Auch diejenigen unter den Besuchern, die bef├╝rchtet hatten, dass alles nicht mehr so sch├Ân gem├╝tlich sein w├╝rde, waren am Ende zufrieden. Der Karlsruher und Heidelberger Teil der SotM-Working-Group haben viele Fragen gekl├Ąrt, den Zeitplan f├╝r das n├Ąchste Jahr aufgestellt und das Konferenzformat festgelegt. Ein Protokoll wird demn├Ąchst auf den Wiki-Seiten der OSMF zu finden sein. Auch die JOSM-Entwickler, die sich teilweise noch nie getroffen hatten, waren sichtlich produktiv und haben endlos Bl├Ątter auf dem Flipchart vollgeschrieben.

Wir freuen uns schon auf das n├Ąchste Hackweekend im Februar 2019!