OpenStreetMap logo OpenStreetMap

Our (the Swiss OSM communities) TIGER moment

Posted by SimonPoole on 4 March 2026 in English. Last updated on 6 March 2026.

OpenStreetMap old timers know about the infamous 2009 TIGER import of road data in the US that continues giving to this day. Our story has none of the, maybe deliberate, shenanigans (see the TIGER improvement project) that went on back then in the US, but there are clearly some similarities in the lessons that should be learnt.

Back in July of 2011 the Swiss community undertook a big effort to import municipality boundaries from swisstopo (the marketing name of the federal Swiss GIS department) (see osm.wiki/Switzerland/swissBOUNDARIES3D). Being an OSM n00b at the time with just a bit over a year editing experience I didn’t really do anything useful for the import proper, but I did organise the explicit permission needed from swisstopo as this was many years before their data would become available for use on open terms for us in September 2021. With a couple of technical hiccups along the way that are not really documented, we finally managed to complete the work by early August.

Fast forward to today: I’ve been going on for a few years now that we really need a quality assurance process so that we can discover and track differences between swisstopos data and what is in OSM. We knew and fully expected that there would be differences, because:

  • at the time of the import we simplified the boundaries quite significantly because of the resource constraints of the computer hardware available to us,
  • over the last 14 years we independently followed the mergers and other changes of the municipalities (see osm.wiki/Switzerland/2026_Municipality_Mergers), and didn’t expect this to improve the accuracy of the boundaries, and we knew that now and then there would be associated minor geometry changes that we wouldn’t be able to track,
  • and then just general decay due to glueing and accidental modifications.

Thanks to work by our community member habi inspired by earlier work by Branko Kokanović from Serbia, we have now have daily QA data and boy, we were wrong.

We had already got an inkling of the real issue back in 2024/2025 when we started getting complaints from the French community and an unnamed big tech company about municipality boundaries in lakes (see https://community.openstreetmap.org/t/heads-up-municipality-boundaries-in-lakes/125007). At the time we assumed that this was simply due to cantonal policy changes that annoyingly hadn’t been included in the Federal Statistics Office municipality mutations documentation (this is what we use to determine which and when to merge or otherwise change municipalities) and we duly fixed all of those that we were aware of last year.

As said, this was annoying, but largely inconsequential as we are talking about water areas with no really relevant infrastructure.

But looking at our newly generated QA data it was clear that not only did we have another bunch of border in lakes issues (see https://community.openstreetmap.org/t/municipality-borders-in-lakes-yet-again-but-with-a-twist/141020) including some really weird things in the Thuner- and Brienzersee, there was a larger numbers of significant differences, for example every single municipality border in the canton Ticino (the Italian speaking part of Switzerland), and not only that: inspection of the data revealed that all these issues had already been present in the original data that we had imported back in 2011.

What we hadn’t realised back then was just how much the swistopo data was a work in progress, and I while I would note that swisstopo didn’t put a big red warning about this on their documentation, there was no deliberate subterfuge on their behalf, at worst somewhat exuberant marketing. We were simply blinded by the belief that this was the gold standard and naively assumed that any errors would be ours.

The good news is that habi and myself have fixed the most egregious issues over the last two weeks and with some more chipping away we should soon have a better than good enough set of boundaries available.

habis work can be found here: https://github.com/habi/swissboundaries

PS: we’ve come a long way since 2011: I’ve done all the boundary work on my phone that can easily hold the full complement of swisstopo boundaries as a geojson layer.

Discussion

Log in to leave a comment