Home  |   About  |   Energy  |   Politics  |   Software  |   Music

05 March 2012

Trouble with OpenStreetMap

I'm a big fan of OpenStreetMap (OSM), a collective effort to map the world on a voluntary basis. The idea is simple: anyone possessing a georeferencing system can collected data on the various features of their neighbourhood or the places they travel. This data can then be committed to a central repository and made available to everyone else in the world. With time the OSM data base has achieved a remarkable extension, detailing many parts of the world, especially the most populated of those. This data is also served freely by several instances around, you can try it at the project website OpenStreetMaps.org.

For some time I have been using the OSM data as base layer for the web GIS applications I work with, taking advantage of handy libraries like OpenLayers facilitate their use. Especially during prototyping it is quite convenient, but even in later stages can be useful as well, considering the amount of data it provides for some places: buildings, cultural sites, transport infrastructure and more. Recently I employed OSM data on a European wide project focused on urban planning and the outcome was quite unexpected.

Everything was going fine until I started using the data provided by the Ludwigsburg city council. The first layer I used contained the building footprints and it was immediately obvious there was some sort of shift between this data and the OSM base layers. I didn't record a snapshot of those first experiments, but where's what it looked liked, with the city council data on grey and the OSM vectors in blue:


My first suspicion was this being a result of the datum shift between the OSM layers provided through web map services (WMS) that use a spherical geodetic datum and the WGS84 datum backing the coordinate system in which the Ludwigsburg data was being accessed. To make sure this was the case I downloaded the OSM data for the Ludwigsburg area, converted it to shapefile format with QGis (the only program I could find that does this, by the way) and published it with MapServer. The OSM data is collected with reference to the WGS84 datum, hence no datum shifts should be at play. Plugging this layer to a test OpenLayers map I got the following (once again OSM vectors are in blue and Ludwigsburg data in grey):


The shift remained, but even worse, it is not at all constant. Besides that, some building shapes markedly differ from the city council data.


I then tried overlaying the Ludwigsburg data on another spherical geodetic datum backed dataset: GoogleMaps. This way everything falls perfectly in place. Here's an example: the aerial photography in the following image is provided by Google, the single colour lines are bus lines provided by the city council and the silver outlined lines are once again the OSM data. While the former align fairly well with the aerial photo, the later shows a shift of some 5 meters to the South-West.


Further investigation showed than not even the shift is constant. In the Western part of Ludwigsburg there are OSM shapes with simple westward shifts:


In the North of the city the shift is mostly Northwards; note also the assorted errors in relative placement and geometrical form of the OSM shapes:


I am not entirely sure what is exactly going on. I see two main hypotheses:
  • The Ludgwisburg data was acquired or produced in a local reference system, based on a datum positioned relatively to Potsdam and the projection into WGS84 is introducing the discrepancies. The problem with this hypothesis is the GoogleMaps data falling in place; has Google magically twisted their data to fit the local reference system?

  • The OSM data was acquired in some erroneous way. A possibility would be a digitalization from non orthorectified aerial photography, but in this case the shift would be more uniform.

At this stage I am trying to get my hands on some geodetic coordinates for Ludwigsburg, either astronomical observations or GNSS data of well identifiable locations to help sorting out this mystery. In any case, the usage of OSM as base layer for this particular project is ruled out; even if it turns out to be correctly positioned, the low quality of its shapes is by itself enough an impediment.