Defekte PLZ-Boundaries im Wochentakt

dooley · 2018-04-05T08:05:06.000Z

Moin.

Wenn ich mir “meine” Statistik auf https://osm-suspects.gbconsite.de/statistic anschaue, fällt auf, dass praktisch im Wochentakt PLZ- und wahrscheinlich damit auch administrative Grenzen aus unterschiedlichsten Gründen defekt sind und zumeist von einigen wenigen Usern mehr oder weniger zeitnah wieder repariert werden (müssen).

Meine Vermutung ist, dass diese Fehler erzeugt werden, weil in den Editoren nicht ein deutlicher Hinweis kommt, dass genau dieser Node, den man verschiebt, ein Teil von einer oder mehrerer Relation(en) ist. Ob vor dem Hochladen/Speichern dann eine Prüfung auf valide Geometrien aller ggf. beteiligten Relationen erfolgt, entzieht sich meiner Kenntnis.

Jedenfalls ist es für Datendownloader und -weiterverarbeiter reine Glückssache, ob in ihrem Extrakt valide Grenzen drin sind oder nicht IMHO ein sehr unglücklicher Zustand.

Wollte ich nur mal bemerkt haben, vielleicht kommen irgendwelche Ideen, wie man das vermeiden könnte.

Gruß, Frank

Edit: Aktuell https://www.openstreetmap.org/relation/1291689#map=15/50.8312/12.9064 und https://www.openstreetmap.org/relation/1291700#map=16/50.8278/12.8944, gefunden auf https://osm-suspects.gbconsite.de/liste/boundarypostcode

chris66 · 2018-04-05T08:14:48.000Z

IMO ließe sich das nur durch auslagern (separate DB für Grenzen) lösen.

toc-rox · 2018-04-05T08:23:26.000Z

dooley:

Wollte ich nur mal bemerkt haben, vielleicht kommen irgendwelche Ideen, wie man das vermeiden könnte.

Alle administrativen Grenzen sollten vollkommen unabhängig von allen anderen Objekte definiert werden, und nur noch durch berechtigte Benutzer editiert werden können.

Jo_Cassel · 2018-04-05T08:55:16.000Z

Um unbeabsichtige Verschiebungen von PLZ-boundaries und der boundaries:administrative zu vermeiden habe ich die bei mir quasi vom ersten Tag an in JOSM rausgefiltert.

Im CAD-Bereich löst man dies seit Jahrzehnten(!) über Layer (“Ebenen” - nicht zu verwechseln mit OSM-“layer” wie “-1”)

boundaries unterscheiden sich von den meisten anderen OSM-Objekten dadurch, dass sie nicht ohne weiteres on the ground oder per Luftbild nachvollzogen werden können. Wer da etwas verschiebt sollte sich vorher mit dem Thema berschäftigt haben und wissen was er da tut. Insofern sollten ALLE boundaries per default in den Editoren gesperrt sein und erst auf ausdrückliche Zustimmung des Mappers (“Ja, ich weiß was ich tue”) zur Bearbeitung freigeschaltet werden.

chris66 · 2018-04-05T09:04:19.000Z

Jo Cassel:

Im CAD-Bereich löst man dies seit Jahrzehnten(!) über Layer

Das geht aber nur wenn die Elemente nicht verklebt sind, wie teilweise in OSM.

Jo_Cassel · 2018-04-05T09:12:30.000Z

chris66:

Jo Cassel:

Im CAD-Bereich löst man dies seit Jahrzehnten(!) über Layer

Das geht aber nur wenn die Elemente nicht verklebt sind, wie teilweise in OSM.

Eben, die Ebenenverwaltung im CAD dient dazu, dass ich Punkte aneinander ausrichten kann OHNE zwingend shared Nodes zu produzieren, denn dies ist bei boundaries eben nicht immer eine gute Idee …

MitteloberrheinischerWaldameisenschreck · 2018-04-05T09:23:04.000Z

toc-rox:

Alle administrativen Grenzen sollten vollkommen unabhängig von allen anderen Objekte definiert werden, und nur noch durch berechtigte Benutzer editiert werden können.

Dann wäre der Fehler, den ich die Tage korrigiert habe, halt drin geblieben …

Die Grenze lag, warum auch immer, am Bach, und so landete ein Haus aus Badisch-Steinhäusle in Schwäbisch-Steinhäusle und fiel dort dem Noteneröffner wegen doppelter Hausnummer auf …
Wegen der korrekten PLZ-Zuordnung war der Kreisgrenzenfehler offensichtlich, andere Quellen zeigten die Grenze aber auch am Weg und nicht am Bach.

Stadtteilgrenzen sind oft anhand der Straße definiert, links der Straße Weststadt, rechts der Grenze Oststadt. Wenn man dann die Straße nach Luftbild korrigiert, ist es auch sinnig, eine evtl. Stadtteilgrenze anzupassen. Bei “richtigen” Grenzen zwischen (ehedem) selbständigen Gemeinden muss man besser aufpassen und recherchieren, weil da kann immer noch die Definition gültig sein, die aus einer Zeit stammt, als die gerade Schnellstraße noch 'n hakenschlagender Feldweg war …