Vor einem guten Jahrzehnt wurden die (Gemeinde)Grenzen der Schweiz von swisstopo in OpenStreetMap importiert: Switzerland/swissBOUNDARIES3D - OpenStreetMap Wiki
Seither wurden die immer mal wieder händisch gepflegt, wenn Gemeindefusionen oder so anstehen.
In den paar Jahren haben sich auch Fehler angesammelt, die mal korrigiert werden müssten.
Aus einer .shp-Datei (die swisstopo zur Verfügung stellt) eine .osm-Datei zu erstellen. Diese Datei könnte dann direkt benutzt werden, um in JOSM die bestehenden Grenzen mit den neuen zusammenzuführen.
Die Qualität der Grenzen in OpenStreetMap zu messen und zu kontrollieren. Dabei wird im Zusammenspiel mit Overpass Turbo eine Tabelle generiert, die die Übereinstimmung der Grenzen in OpenStreetMap und der Grenzen im Datensatz von swisstopo beschreibt. Dieser Teil des Tools läuft für Serbien täglich, so dass die Grenzen kontrolliert werden können und bei ‘Beschädigung’ eine Korrektur möglich ist. Das Skript könnte auf einer virtuellen Maschine (welche die SOSM zur Verfügung stellt) laufen, und einen Bericht erstellen, der öffentlich zugänglich wäre.
Die erstellte .osm-Datei direkt in OpenStreetMap einzupflegen. Damit das nur ansatzweise möglich ist, müsste der ganze Vorgang sicher vorgängig breit diskutiert werden.
Es könnte auch sein, dass die Nachbarländer eingebunden werden müssen, denn die äussere Landesgrenze betrifft ja einige weitere Länder und OSM-Gemeinschaften
In einem ersten Schritt wäre es wohl schon mal gut, wenn der 13-jährige Import mal mit einem frischen Umbau in eine .osm-Datei kontrolliert und korrigiert würde.
Sollte das mit dem damaligen Account (SwisstopoImports | OpenStreetMap) gemacht werden?
ich finde das eine sehr gute idee, auskennen tu ich mich da nicht wirklich. verzeih deshlab wenn meine fragen anfängerhaft scheinen: was bedeutet die bestehenden grenzen mit den neuen “zusammenführen”, technisch gesehen? kann man punkt 2, eine tabelle generieren, auch machen ohne dieses zusammenführen? wie funktioniert punkt 3, dieses einpflegen, technisch?
Hab jetzt die Frage nicht ganz verstanden (ausser wegem alten Konto, das würde ich vorschlagen weiterzuverwenden).
Die ursprünglichen Daten nochmals zu nehmen macht schon deshalb keinen Sinn weil eine nicht kleine Anzahl der Gemeinden verschwunden sind in der Zwischenzeit (eben was wir autonom nachvollzogen haben, sprich ohne swisstopo gemacht haben, und auch weiterhin in irgendeiner Form machen sollten). Das andere Problem, ist das damals aus technischen Gründen stärker vereinfacht wurde als was man heute machen würde, die offene Frage ist natürlich wie stark wollen wir -jetzt- vereinfachen?
Zusammenführen ist (m)eine Deutsch-Übersetzung von Conflation. Der Prozess beschreibt das Zusammenführen von zwei Datensätzen, d.h. neue und potentiell bessere Daten einer erlaubten Quelle mit den bestehenden Daten in OpenStreetMap zusammenführen. In der Schweiz können z.B. die Addressdaten aus dem GWR mit JOSM mit bestehende Addressen zusammengeführt werden.
Ja, das kann das Tool von @Branko_Kokanovic auch so. Er hat mir die Tabelle zugeschickt Die Idee ist, dass eine solche Tabelle auf einer Webseite ersichtlich ist, damit wir quasi eine Überwachung der Datenqualität der Schweizer Gemeindegrenzen in OpenStreetMap gegenüber den ‘Originaldaten’ von swisstopo haben.
Das Tool zieht sich aus Overpass die bestehenden Grenzen, schaut in den swisstopo Daten, welche genau dazu passt und ersetzt allenfalls schlechtere Daten in OpenStreetMap mit den Daten von swisstopo.
Ja, ich gebe zu, dass im ganzen Post keine wirkliche Frage versteckt war
Die Idee wäre ja schon, dass die Grenzen in OpenStreetMap gegenüber dem aktuell gültigen Stand von swisstopo aktuell gehalten würden, das wäre dann aber erst im dritten Schritt mit der automatischen Conflation…
Wenn ich das richtig verstehe, könnten die Daten in OSM dann genau den Daten im swisstopo-Shapefile entsprechen.
Also würde ich
mit ‘gar nicht gegenüber den swisstopo Daten’ beantworten.
Ich weiss aber nicht, ob das in einem ersten Schritt heisst, alle 2278 Gemeindegrenzen, die es im November 23 im Shapefile von swisstopo gab einzeln manuell mit den bestehenden Grenzen in OpenStreetMap zusammenführen muss…
Da müsste Michael was dazu sagen, damals war das gar nicht möglich wenn ich mich richtig entsinne. Es mag jetzt natürlich besser sein, muss man aber vermutlich ausprobieren.
(Entschuldigung, dass ich auf Englisch antworte. Ich hoffe, es macht dir nichts aus. Ich sehe, dass Discourse gut in der Übersetzung ist.)
I think first thing is to set up reporting page. Reporting is done using IoU metric on OSM vs swisstopo. Then you can see what are averages, how good you are, what are max/min and see if there is any obvious errors in OSM (or just something that you want to keep different than what is in swisstopo).
Next, really harder part, is to do automatic conflation (with approval from community, of course). I used tool for automatic conflation, but it was in “manual” mode (lot of cases covered with manual coding…). First questions you want to ask yourself is:
do you want pixel-perfect boundaries (at all) and what simplification you want
do you have open data from neighborhood countries and do you want to touch those national borders at all
what you want to do with non-physical boundaries, like “national parks” and similar. Should they follow administrative boundaries or not? Answer in Serbia was “yes, follow, keep attached”.
Same thing, but for physical boundaries, like roads, rivers etc. Answer for Serbia was “no, detach them”
I have to remember process, it was long time ago (if someone wants to step in and do it yourself - I will be grateful, I can do hand-holding and explaining the code), but only thing that I was able to automate was if administrative boundary way was completely detached from everything else - in that case, tool can shapeshift it easily and is good for that. Those should be 50%-80% of ways. However, there will be long tail of cases where it will fail (tool will however tell you for each way why it failed and some cases can be automated as well, depends how much effort you want to put into coding):
endpoints are too far away
there is node with tags in way
there is another way/relation attached
boundary ways are split in multiple segments
…
I would advise to look at my presentation in https://www.youtube.com/watch?v=5hYuKcKwXDk which gives more insight (unfortunately, due to time, I couldn’t get into juicy details…). I will be reading and following this topic, feel free to continue in German!
No excuse necessary.
I deliberately posted in German and fully expected to read responses in other languages!
As you say, the Discourse translation works surprisingly well.
Before the final run of the tool, I wrote an Overpass Turbo query to identify nodes shared between boundaries and other types of ways (which was supposed to be a no-no, but some mappers just love to glue things together so that they look “tidy”). Then I inspected those cases and detached the ways manually, in iD. That allowed a clean(er) run of the tool, since we were basically left with a boundary “layer” independent of other objects.
Found it… http://overpass-turbo.eu/s/PX2
…however, upon review, it does not do what I said above – it merely finds ways that are double-tagged as a boundary and something else (waterway or highway). I knew I wasn’t that good with Overpass queries…
Still, running it for Switzerland reveals that a good part of the Aare river is double-used as a boundary and a waterway, as well as several other ways across the country. This may or may not be desired – it’s a matter of local convention. Still, I hate such practice…
I’ve started to clean up boundaries double-tagged as waterways, based on the Overpass turbo query from @Duja.
Changeset comments should always include “#swissboundariescleanup”, so they can be found with OSMCha (I don’t know if the link works for non-me users ).
If someone wants to help, just go for it!
