Municipality borders - QA and fixes

Communities Switzerland
1

I’ve penned a short blog post on the background here SimonPoole's Diary | Our (the Swiss OSM communities) TIGER moment | OpenStreetMap

@habi and myself have been working on getting rid of the worst issues over the last couple of weeks and I don’t think that a general call to action is needed before we get a better feeling for the remaining work. Fixing the borders is not particularly difficult but is complicated by historic boundaries, glueing etc. and I’ve used different methods from simply manually moving nodes to complete replacement depending on what makes most sense.

The good news is that we can track changes now and that is already 99% of the solution.

Note that the numbers are currently slightly off for municipalities containing exclaves most noteably Ronco sopra Ascona

2 Likes
Address and Street Data Updates
Border edits Italy - Switzerland (was Vacallo - Como)
2

Just a small update on this:

  • all municipalities with really bad iou (intersection over union) and very large area differences have been updated.
  • we’ve started work on fixing those now that show a large Hausdorff-distance, these are mostly due to geographically limited changes to the borders and typically come in pairs, however a couple of them are due to mapping errors (see below) .
  • the issue with exclaves aka holes not being accounted for properly has been fixed.

The code from @habi writes a log of the value changes and if you are interested in how things have changed you can check in the history folder swissboundaries/history at main · habi/swissboundaries · GitHub

Given that these boundaries have 15 years of history behind them some issues are to be expected:

  • “historic” (aka don’t exist) boundaries these have mainly been created by our annual update of the boundaries due to mergers etc. These are an issue as they require splitting the new geometries at the appropriate locations, and at some times they don’t even exist as the boundaries have changed so much that the topology can’t really be recreated without leaving the boundary ways from 2011 in place, which I hope we agree we don’t want to do. This will now and then lead to breakage of historic boundaries that we’ll fix, but with low priority.
  • mapper induced issues:
    • one interesting case is Hombrechtikon that had the 3rd highest Hausdorff-distance. The underlying reason was that a mapper added the postcode area for Feldbach and changed the external boundaries of Hombrechtikon to conform to that. That has been fixed, but the (useless, see the prior discussions) post code area for Feldbach is currently broken, I’ll fix that contre coeur but again low priority.
    • use of boundary nodes and ways for unrelated purposes. Glued objects should in general only rarely cause problems, however there have been issues with non-boundary objects being tagged on the boundaries. Most notably the lake area of the Lac de Neuchâtel has sections where it has been tagged on the boundary instead of a separate object (which could have been unjoined). This is the reason why I temporarily emptied the lake, it has been refilled :-), but that required redrawing sections of the shoreline (that undoubtedly could be improved). The problem continues to exist for the shore line of Neuchâtel itself, and that will need to be redrawn before we update that boundary.

Some further notes: most of the boundaries have been updated by using a “replace geometry” function, this has the advantage that it reuses the original ways and nodes (retaining the object history), but has the disadvantage that it doesn’t create a change at the level of the boundary relation itself. This is somewhat unsatisfactory, and would suggest that we update the tags on the boundary objects to a) get rid of nonsense (for example the BFS district number and other 3rd party keys that we don’t need), b) indicate that the actually geometry has been updated from current swisstopo data.

1 Like
3

We have a problem.

As you can see if you sort the list at https://boundaries.osm.ch/ by Hausdorff distance (and ignore Eschenz), essentially all of the remaining borders with really large differences are in the alps. The reason I haven’t continued working on them is that we have the problem that in some cases peaks have been joined to the border and my normal procedure would be to unjoin anything tagged that would have to be moved more than 1m (that is fairly arbitrary but would seem to be a safe assumption).

Now to be clear the original and current swissBundaries2d data doesn’t contain information if a peak defines the border or not so all the peaks that have been joined to the borders after the fact, typically without indication of if the joining was based of any clear source.

A good example of this is the Mettelhorn (which many have likely already been on and have a good idea of what things look like on the ground). The Mettelhorn is at least* nearly on the boundary between Zermatt and Täsch:

The position in OSM of that border node it is joined to is roughly 2.5m off the new position of the border and therefore I would normally unjoin it. However there are arguments that I can understand that this breaks topological consistency and should be avoided.

Any opinions?

* the coordinates from swisstopo for the Mettelhorn are around 10cm away from the closest border vertex (both in LV95 coordinates).

PS: we have the same issue at an international level with the boundary to Italy in the mountainous areas but at least there there is a further dataset from swisstopo that contains data on the boundary points.

4

Ich hab’ das auch gesehen, als ich versucht habe Relation: ‪Täsch‬ (‪1685386‬) | OpenStreetMap zu verbessern.
Dort ist mir insbesondere Node: ‪Chummenchlene‬ (‪1373118652‬) | OpenStreetMap aufgefallen, weil die laut map.geo.admin.ch nicht am selben Ort ist wie in OSM Maps of Switzerland - Swiss Confederation - map.geo.admin.ch

Rund um Node: ‪Allalinpass‬ (‪3206071359‬) | OpenStreetMap ist die Grenze laut swissBOUNDARIES3D ca. 35m verschoben, das Node: ‪Allalinhorn‬ (‪316985775‬) | OpenStreetMap ist dann nur ca. 1m unteschiedlich.

Ich habe auch grad keine klare Herangehensweise, wann Knoten entklebt oder nicht werden sollten…

5

Das Problem ist es ist schwierig zu unterscheiden zwischen dem Fall:

  • Gipfel definiert tatsächlich einen Vertex der Grenze, wie es zum Teil an der IT-CH Grenze ist, zum Beispiel mit Gipfelkreuzen, topologisch wäre also das Verbinden richtig.

und

  • Gipfel ist sehr nahe an der Grenze aber nicht Teil, dass scheint beim Mettelhorn der Fall zu sein.

Und bis jetzt hab ich keine Dokumentation dazu gefunden, aber vermutlich könnt man die entsprechenden Vermessungspunkte dazu anschauen.

Was meint @Geonick als Fachkraft dazu?

1 Like
6

This continues to stall improving the boundaries in all mountainous cantons. We really need a community wide consensus on how to handle this.

7

Weils so schön ist …

image
image1745×901 368 KB

4 Likes
8

Du wotsch doch nume chli plagiere mit däm Aargou.

1 Like
9

A short update on the progress (I prefer Hausdorff distance* as the relevant metric over IoU, but YMMV):

  • we have improved things to the point that only ~270 of 2110 borders have more than 10 meters difference. Work on those 270 is stalled due to Municipality borders - QA and fixes - #3 by SimonPoole
  • the median Hausdorff distanz is around 3.5m, and a lot of the boundaries have distance values that are near the OSM maximum resolution (sadly that won’t stay that way) for Switzerland.

Reminder: when we imported the boundaries we simplified them as at the time we couldn’t deal with the amount of data from the original boundaries. It seems as if nobody can remember exactly which tolerance value was used during simplification, but it was likely something between 2 and 5 meters. With other words we already have a large number of borders that are significantly better than those from the original import.

As to the mountain peak and boundary stone problems: I had some hope that we could, at least for the international borders, use information from swisstopo’s boundary point dataset that provides some meta information on the points along the borders, For example if the point is marked with a boundary stone, a cross (on peaks), a bolt etc. This seems to be somewhat helpful wrt boundary stones along the French and likely the German border, but what I’ve looked at up to now less helpful for resolving the mountain peak issue. In particular the data doesn’t include elevation information and any indication if it is a peak or not (you kind of could of assume it for crosses).

See for example the data near this well know mountain peak:

https://map.geo.admin.ch/#/map?lang=en&center=2617037.16,1091683.64&z=13&topic=ech&layers=ch.swisstopo.swissboundaries3d-land-flaeche.fill@features=CH;ch.swisstopo.hoheitsgrenzpunkte-landesvermessung@features=11646&bgLayer=ch.swisstopo.pixelkarte-farbe&featureInfo=default&catalogNodes=ech,457,532,510

The other issue with the boundary nodes is, from the small sample that I’ve looked at, there are “main boundary nodes” that are not actually part of / on the boundaries data distributed by swisstopo. I’ve asked swisstopo about this and it may be just an expected inconsistency that we have to live with.

See an example here Maps of Switzerland - Swiss Confederation - map.geo.admin.ch

Actually this shows the issue better

image
image1080×2316 450 KB

* that is in practical terms the maximum difference between our data and swisstopos, that is less a measure of how similar the geometries are, but more if there are any big differences, which could, for example, just be a big spike because somebody dragged a boundary node.

10

I’ve now slowly started work on the “problematic” borders, that is those that have merged peaks.

My current process is:

  • tolerance during replace geometry 1m, that is tagged objects that would be moved more than that are extracted from the border way.

  • merged peaks with no name: ignore

  • saddles: ignore

  • unmerged peaks: ignore

  • merged peaks: move to current (these things change) position according to swisstopo*

  • peaks near an international border: check the swisstopo border point data if there is actually a border point near the peak location that would indicate that it is actually a defining point of the border (what that topologically implies for the location of the peak is unclear)

Luckily lots of the peaks along the borders are not actually merged, just very nearby, or are so far away after adjusting their position that there is no debate.

An other issue that I’ve noticed is that there tends to be lots of situations in which secondary and main peaks seem to be mixed up or given the same name, this doesn’t have a bearing on the above, but at some time in the future this could be a candidate for some separate QA.

* with other words if the updated position is still < 1m from the border it will remain merged.

11

From what I found the borders in a natural context are defined by watersheds and must not necessarily run through peaks, so unlike my previous assumption, having a peak close but not on the border is a possible situation. The exact location for the coordinates of the Swiss-Italian border are established by a bilateral commission, which will update the coordinates when the terrain (watersheds) changes. Assuming swisstopo has the latest version of these official agreements, it seems a viable approach to the issue taking their information as good, at least as long as we do not have evidence that the neighbouring country has a different view on the position.

12

DBSN boundaries shows Italian official borders and they seem to match the swisstopo ones where they have been updated (there are still lots that haven’t been) quite well.

See ~~ DBSN boundaries for a bit with our “old” boundaries.

image
image1897×969 377 KB

1 Like
13

Seit letzter Woche werden von boundaries.osm.ch auch die Grenzpolygone in Liechtenstein überwacht.

Die Gemeindegrenzenpolygone haben in der Schweiz swisstopo:BFS_NUMMER als bijektive Referenz zur BFS-Nummer, während in Liechtenstein bfs:OBJECTVAL benutzt wird. Deshalb habe ich die Overpass-Abfrage in meinem Tool deutlich ausgebaut, nämlich suche ich nach allen boundary=administrative mit admin_level=8 auf der Schweizer Overpass-Instanz. Weil da wegen nicht perfekter Grenzziehung im Schweizer Extrakt auch Grenzpolygone aus Frankreich, Italien, Österreich und Deutschland auftauchen, wird meine Overpass-Abfrage etwas komplizierter, aber wenigstens verwenden alle Nachbarländer eine eindeutige Key/Value-Kombination bei den Grenzpolygonen.

[out:json][timeout:120];
area["ISO3166-1"="CH"][admin_level=2]->.switzerland;
area["ISO3166-1"="LI"][admin_level=2]->.liechtenstein;
(
  relation["boundary"="administrative"]["admin_level"="8"]["type"!="historic"]["ref:FR:SIREN"!~".*"]["ref:at:gkz"!~".*"]["de:amtlicher_gemeindeschluessel"!~".*"]["ref:ISTAT"!~".*"](area.switzerland);
  relation["boundary"="administrative"]["admin_level"="8"]["type"!="historic"]["ref:at:gkz"!~".*"](area.liechtenstein);
);
out geom;

D.h. swissBOUNDARIES3D <-> OpenStreetMap zeigt jetzt auch den Zustand der Gemeindegrenzen in Liechtenstein. Hallo Nachbarn :slight_smile:

Und der Umweg über die Referenzschlüssel bringt mich darauf, dass wir in der Schweiz wohl von swisstopo:BFS_NUMMER einfach zu ref:ch:bfs wechseln sollten, das aber mal nur so nebenbei.