Genauere Verwaltungsgrenzen in BaWü vom LGL-BW

… also gibt es mehrere Objekte mit dem gleichen de:amtlicher_gemeindeschluessel ??

Kann man das mal als Liste irgendwie zusammenstellen, durch eine Auswertung via Datenbank oder OverpassAPI?

Anpassen heißt für mich löschen - ich will ja nicht ohne Not neue Schlüssel a la old_de einführen. Das Tagging auf obsolete_ sollte genügen. Ich war so naiv anzunehmen, dass man den boundary-Schlüssel überprüft, bevor man boundary-Eigenschaften auswertet.
Ich werde auch noch die TMC-Schlüssel und postal_codes entfernen, damit nicht etwa ein fahrlässig programmiertes Routing o.ä. zwei Gemeinden anzeigt, auf deren Gebiet man sich befände.
Weitere Schlüssel und die Relationen selbst lasse ich noch, da z.B. in Konstanz die Stadtteile ganz kreativ als geschlossenene Multipolygone angelegt sind, die dann als Subrelation in die Grenzrelation eingefügt wurden. Das würde ich in der alten Grenz-Relation erst nach Bereinigung entfernen.

Bei mir heißt anpassen = anpassen, also entweder löschen oder verändern. old_de:amtlicher… ist auch noch nicht lange in Gebrauch und die Original-Keys machen an den alten Grenzen keinen Sinn mehr, das ist einfach eine Fehlinfo. Bei mehr als 6000 Gemeinden/Städten in Deutschland, die täglich ausgewertet werden, gibt es schon etliche Varianten und diese alten Grenzen kommen halt als potentielle Grenzen für mich infrage. Es gibt auch Fälle, wo admin_level falsch eingestellt ist. Das läuft alles in Logfiles aus und muß an und zu kontrolliert werden und wenn da nicht so viel false-Meldungen auftauchen, ist mir das lieb.

Ich bin in dem Fall ausnahmsweise froh, das für Baden-Württemberg nur so wenige Straßenlisten existieren. Wenn in Kürze von der LGL für ganz BaWü die Straßenlisten verfügbar werden, werden die nicht nur ausgewertet, sondern es werden mit Sicherheit auch einige/viele fehlerhafte Grenzen auftauchen und dann werden die Menge als veralteten Grenzen einfach die Fehlersuche verkomplizieren.

Grüße

Dietmar

Eine Liste hat sich erledigt, die wurden bis auf 4 schon bereinigt. Die 4 habe ich dann noch bearbeitet. Meine Rechereche erfolgte über meine lokale OSM-DB, die zeitlich ziemlich aktuell ist.

Viele Grüße

Dietmar

Ist das eigentlich abgeschlossen? Hier laufen immer noch alte und neue Linie parallel und sind beide mit boundary=administrative getaggt:

http://www.openstreetmap.org/browse/way/42557946
http://www.openstreetmap.org/browse/way/207106803

Nö, natürlich nicht - genausso wie ich es erwartet habe. und die obsolete_boundary sind auch noch alle da.
der Herr treibt sich jetzt lieber in wärmeren Gefilden rum: http://www.openstreetmap.org/user/seichter/edits

Das und weitere (meist Kreisgrenzen) wurde bereinigt. Am Rand des bearbeiteten Gebietes (im wesentlichen RegBez TÜ) bleiben aber doppelte Linien, da sonst weitere Grenzen “im Leeren” enden würden.
“obsolete_boundary” darf jeder gerne löschen, der vor Ort sicher ist, dass die LGL-Grenzen besser sind und wenn sie in keinen aktiven Relationen (z.B. admin_level=7,9,10) mehr enthalten sind.
Off Topic @wambacher: Rumnörgeln vom hohen Roß herunter wirkt nicht unbedingt motivierend, hilfreiche Hinweise fände ich besser, in grauer Vorzeit gab es mal etwas namens Netiquette …

Ich bin nicht aus der Ecke, und ich bin nicht ganz so “import-kritisch” wie manch einer hier. Trotzdem wäre aus meiner Sicht eine andere Vorgehensweise angemessener gewesen:

Entweder den Import komplett planen, wenn eine vorhergehende Diskussion den Schluss zulässt, dass die Daten insgesamt besser sind als die vorhandenen. Komplett hieße dann aber auch inkl. Übertragen der Relationszugehörigkeiten, Entfernen (oder noch besser Ersetzen) der alten Grenzlinien, Plan für die absehbaren Probleme wie die angesprochenen Anschlüsse an den Außengrenzen des Imports.

Oder, wenn manuelle Nachbearbeitung unumgänglich erscheint, vorab lokale Mapper zusammentrommeln, die dazu bereit sind, bzw. nur das Hochladen, was man selbst nachbearbeiten kann und will.

Die doppelten Knoten sind jedenfalls mit Ausnahme einer Grenze nördlich von Ulm beseitigt. Zu mehrfachen Wegen kann ich nichts sagen.

Aber falls jemand anderweitig aufräumen will, es gibt auch Doppelknoten aus sonstigen Quellen. Aktuell für BW: http://toolserver.org/~mapjedi/dupenodes_bw.osm.bz2
(Diese Datei nicht bearbeiten/hochladen, sondern als Hintergrund/Hilfsebene verwenden, um Hotspots zu finden. Die kontaminierte Region in eine neue Ebene laden, bearbeiten, hochladen.
Für Fortgeschrittene: Vor dem Herunterladen der tatsächlich zu bearbeitenden Daten die Knoten in der Hilfsebene auswählen, nach dem Bearbeiten bereinigen -nicht: löschen.)

Gerade ist mir aufgefallen, dass am 10.3. in diesem Changeset mit dem wenig aussagekräftigen Kommentar “obsolete → multipolygon” zahlreiche bayerische Gemeindegrenzen von boundary = administrative auf obsolete_boundary = administrative gesetzt wurden, z.B. diese Grenzlinie. Diese Grenzen sind natürlich nicht obsolet und das Tag ist falsch.

Danke für den Hinweis. Da habe ich beim Filtern einer Auswahl offensichtlich übersehen, dass ich auch ein paar Grenzen im Freistaat Bayern mit erwischt habe. Müsste behoben sein.

Soeben habe ich die Shape-Dateien (Gemeinden) mit QGIS nach WGS 84 transformiert und dabei die BeTA2007-Daten verwendet.
Die Grenzen (BW/BY) stimmen jetzt sehr gut überein, maximale Abweichung liegt unter 1 cm (0,01 m).
Ob jetzt die Transformation von seichter oder mir genauer ist, weiß ich nicht.

Danach habe ich mit GRASS die geschlossenen Grenzringe passend segmentiert, so dass sich angrenzende Gemeinden dieselben Linien teilen.
Diese Shape-Datei habe ich dann mit dem OpenData-Plugin für JOSM in eine OSM-Datei umgewandelt, mit passenden source-Tags ergänzt und hochgeladen:
https://www.dropbox.com/s/lmmi7jnc9quqjj0/Gemeindegrenzen_BW.osm
Datenquelle: LGL, www.lgl-bw.de
Lizenz: CC BY 3.0

Viele Grüße,
whb

toll, und nu?
bisher haben wir in OSM da unten noch den Altbestand (obsolete_boundary) als Ways und Relationen, dann die von einigen Wochen importieren Daten und jetzt schon wieder neue Datensätze. Hatte mich erst erschrocken, da man deinen Beitrag auch mit “hab ich dann nach OSM hochgeladen” interpretieren konnte. War zum Glück nicht so - bist ja Profi.

Aber dennoch: wat nu?

Gruss
walter

Fehler gefunden?

Dafür kann ich nichts.
Aber ich bemühe mich sehr ernsthaft darum, es richtig zu machen.
Hilfst du mit?

Entschuldigung, dass du dich erschrocken hast. :wink:
Profi bin ich sicher nicht.

Wenn die Daten in Ordnung sind, dann werde ich mich um die Aufteilung in kleinere Pakete kümmern, so wie hier:
http://wiki.openstreetmap.org/wiki/Bayern/Gemeindegrenzen-OpenData-Initiative

Viele Grüße,
whb

Die Daten sind schon in Ordnung - aber ob die besser sind als die zuletzt leider etwas unglücklich hochgeladenenen, wage ich zu bezweifeln. Hier mal ein Screenshot bei http://www.openstreetmap.org/browse/node/2167410640

rot - alte Daten, die mit obsolete_boundary=administrative getaggt aber immer noch nicht gelöscht wurden
pink - vor einigen Wochen hochgeladenen Daten
grau: “deine” Daten

Die letzten beiden Datensätze stammen ja aus dem gleichen Datenbestand der LDL und sind somit fast identisch: gleiche Nodes mit geringfügiger Verschiebung im Meter-Bereich. Welcher der beiden nun “besser” ist, mag ich nicht beurteilen. Aber “einfach” nur die violetten Ways manuell durch “deine” Ways zu ersetzen, halte ich für viel zu mühsam.

Das könnte übrigens auch eine kleine Umrechnung aller betroffenen Nodes (Formel1 → Formel2) erledigen, wäre aber ein mechanical Edit…

tl;dr: halte ich für unnötig und mache daher wohl nicht mit. Aufräumen wäre ok aber bitte nicht fast identische Ways austauschen.

Gruss
walter

Hallo Walter,

bei beiden scheint die Abweichung zueinander annähernd im Meter- oder sogar im Submeterbereich zu liegen, im Vergleich zu anderen Dingen sehr gering. Angesichts des gleichen Versatzes der im Screenshot sichtbaren 5 Punktepaare halte ich persönlich die Abweichung für ein Ergebnis unterschiedlicher Transformationsmethoden: BETA2007 und “nicht BETA2007” Zur Beurteilung wären auch offizielle Vektordaten zum Vergleich interessant. Ist BW bereits auf ETRS und/oder AAA umgetellt? Dann würden zu mindestens kompaktible Koordinaten zum Vergleich vorliegen.

Sven

Ich habe dieselben Werkzeuge/Daten benutzt wie whb, auch beta2007. Wenn der workflow aber nicht identisch ist, können unterschiedliche Ergebnisse resultieren. Schon das Abspeichern von Zwischenergebnissen und wieder einlesen kann einen Unterschied machen. Per Mehrheitsprinzip halte ich die Daten von Bayern und whb für genauer. Alles unter einem Meter betrachte ich für die Zwecke von OSM aber als irrelevant, deshalb hat mir die kleine Abweichung an der Grenze zu Bayern kein Kopfweh bereitet.
Die LGL-Daten sind noch Gauß-Krüger, BW ist erst dabei, umzustellen. Die freigegebenen Daten sind aber sowieso vereinfacht, für die exakten Daten auf Kataster-Niveau muss weiterhin gezahlt werden.
An der Landesgrenze sind die Stützpunkte offensichtlich mit den Kollegen aus Bayern abgestimmt, im Inneren aber misstraue ich den Daten an manchen Stellen. Man kann es schon am Abstand der Stützpunkte abschätzen: Die liegen sehr oft nur wenige Meter auseinander, gelegentlich aber zig Meter. An der Stadtgrenze Reutlingen sieht man an einer Stelle, wie die Grenze auf den Meter genau zwischen zwei Häusern einer Reihenhauszeile durchgeht (stimmt laut Kataster tatsächlich), an anderer Stelle liegt sie 10 m neben einem OSM-Weg, der nach GPS-Tracks und Bing bis auf ein bis zwei Meter exakt liegt, und auf dem sie laut Kataster verlaufen sollte. An dieser Stelle war die alte Grenze genauer (und ich habe die neue Grenze dorthin verschoben).
Solche Fälle sind die Ausnahme, aber es gibt sie. Das war der Grund, weshalb ich die alten Grenzen nicht löschen wollte.

Zum weiteren Vorgehen: Im betreffenden Gebiet müssten alle Verwaltungsverbünde (level 7) umgestellt sein, momentan binde ich alle Grenzen unterhalb Gemeindeebene (level 9-11, PLZ) an die neuen Grenzen an (sind in den LGL-Daten nicht enthalten) und lösche obsolete-Relationen Zug um Zug, da deren Attribute in den neuen Relationen enthalten sein müssten. Ich bitte aber um Geduld, da ich gelegentlich auch noch Anderes zu tun habe (auf Mithilfe brauche ich wohl nicht zu hoffen). Die Außengrenzen kommen zum Schluss dran, da gibt es aber z.B in Südbaden schon wenigstens einen, der die neuen Grenzen schon Stück für Stück erweitert.

Könntest du das bitte übersetzen?

Ich dachte eher daran, die noch fehlenden LGL-Grenzen einzuarbeiten, nicht die schon eingetragenen LGL-Grenzen nochmals zu verbessern.
Dabei könntest du helfen, denn das ist nicht unnötig. :slight_smile:

Die Frage ist jetzt eigentlich nur, welche aufbereiteten Daten ich nehmen soll, die von seichter oder die von mir.
Würde mich dann von Nordwesten aus vorarbeiten.

Viele Grüße,
whb

Klar, dass zwischen “neu” (pink) und “ganz neu” (grau) kleinere Unterschiede bestehen; beide Datensätze sind aber erheblich besser als die alten Daten. Ich wollte - und will - eigentlich zum Ausdruck bringen, dass ein erneuter Wechsel der Daten nichts bring ausser verdammt viel zusätzliche manuelle Arbeit.

Das hat wohl etwas mit der ziemlich planlosen Vorgehensweise zu tun. Wenn es kein - zumindest für mich erkennbares - Konzept gibt, wie soll man da mithelfen? In Bayern ist das anscheinend besser gelaufen.
Ich hab heute mal in einer kleinen Ecke angefangen, ein wenig aufzuräumen, lese aber jetzt deine Bedenken und frag mich, ob ich weiter machen soll. Zumindest im Norden ist ein Kollege auch aktiv.
Nur so zur Info: es geht um 387 obsolete Relationen mit 1158 obsoleten Ways.

Nochmals: Die Daten sind - für mich - ok, 1000x besser als der alte “Schrott” und sollten drin bleiben. danke

Gruss
walter

Ich habe verschiedene Kombinationen ausprobiert, die Ergebnisse unterscheiden sich kaum.
Die eingesetzten Programmversionen sind hier vermutlich auch von Bedeutung.

Viele Grüße,
whb