@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
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.
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 that doesn’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.