Ich habe begonnen, die Verwaltungsgrenzen aus der Open-Data-Inititive des LGL BW zu importieren
(Quellenangabe: LGL, www.lgl-bw.de).
Diese sind fast immer deutlich genauer als die bisherigen Grenzen (auch etwas besser als die Kreisgrenzen aus dem Infas-2005-Import), an einigen wenigen Stellen aber nicht. Ich habe deshalb die alten Grenzen nicht gelöscht, sondern nur per obsolete_boundary umgetaggt. Die z.T. umfangreichen Attribute der alten Grenzen habe ich auf die neuen übertragen. Dort wo die neuen Grenzen vor Ort bestätigt werden können, und wenn sie von keiner Grenzrelation aus dem Nachbargebiet mehr referenziert werden, können die alten (obsolete_)Grenzen gelöscht werden.
Da die Bayern mit den entsprechenden Daten von der Bayerischen Vermessungsverwaltung praktisch schon fertig sind, habe ich die Landesgrenze gelassen und die LGL-Daten dorthin verbunden. Dies ist problemlos möglich, da die Ways und Nodes aus Bayern und aus BW bis auf weniger als 1 m übereinstimmen.
Der Regierungsbezirk Tübingen ist im Wesentlichen fertig, wer die Arbeit in den anderen Bereichen angehen will, sich den Aufwand für die Konvertierung der LGL-Shape-Files sparen will oder sich mit Projektionstransformationen von Gauss-Krüger zu WGS84 nicht auskennt, kann aufbereitete Shape-Files (fertig zum Import in z.B. JOSM) von mir bekommen.
das heißt, du hast auch alle Grenzrelationen an sich selber im Blick??? Deren stetige Integrität ist nämlich für bestimmte OSM-basierte Produkte sehr wichtig.
Ich nehme mal an, dass du dich darum selber kümmern wirst - oder hast du vor, diesen nicht ganz unwichtigen Teil der Community zu überlassen?
Derzeit sind zumindest die Renderer sehr erbaut, da alte und neue Grenzen parallel dargestellt werden.
btw: type=boundary beim Way ist mir bisher nicht vorgekommen. Dieses Tag (ob nun type=boundary oder type=multipolygon) kenne ich nur an der Relation selber.
Gruss
walter
p.s. irgendwie klemmt das heute bei pic-upload.de 
Ich lade zumindest nur Relationen hoch, die geschlossen sind. Selbst alte Relationen habe ich, obwohl obsolet und von mir nur umgetaggt und sonst nicht verändert, gelegentlich repariert, damit ich im Prüfergebnisse-Fenster von JOSM beim Hochladen keine Warnungen mehr habe.
Alles sehr schön. Ist denn geklärt, dass die Namensnennung nach www.lgl-bw.de/…/Open_Data_Initiative mit unserer Form der Namensnennug per Contributor-Seite zusammen passt. Das ist nämlich bei allen CC-BY Lizenzen immer die Frage, die man dem Lizenzgeber stellen muss.
(Hervorhebungen von mir)
Diese Form der Namensnennung können wir in ihrer reinen Form für aus den OSM-Daten erstellte Produkte (insbesondere Karten) nicht garantieren.
Edbert (EvanE)
Das Löschen ginge mit der entsprechenden XAPI-Abfrage und per Filter in Minuten, das Überprüfen der Grenzen vor Ort allerdings nicht. Noch einmal: Ich wollte so wenig destruktiv wie irgend möglich vorgehen.
Das Tag type= habe ich an ways nicht verwendet, wohl aber boundary=administrative, admin_level= und source=, so wie es auch den alten ways zu finden war. Gelegentlich ist noch ein Tag cat= aus den Shape-Dateien durchgerutscht, die werfe ich gerade raus.
Die Renderer werten offenbar nicht nur das boundary-Tag in den Relationen, sondern auch das an den ways aus. Ich bin deshalb dazu übergegangen, auch die alten ways mit obsolete_boundary umzutaggen. Man soll zwar eigentlich nicht für die Renderer taggen, aber was tut man nicht alles für die Schönheit …
Dir ist schon bewusst, dass es etliche Wiki-Seiten gibt, in denen die Relation-ID fest drin stehen. Die funktionieren nicht mehr, wenn die obsoleten Grenz-Relationen eines Tages entfernt werden.
Vermutlich ist es besser komplett neu aufzusetzen, als den alten Relationen neue Versionen zu spendieren. Schließlich hat man durch den (händischen) Import auch einen komplett neuen Stand.
Aber wie bei jeder Medizin gibt es halt Nebenwirkungen.
Gibt es aus deiner Erfahrung mit dem RegBez Tübingen eine Abschätzung, in wie groß die Abweichung der ‘alten’ Grenzen von den jetzt verfügbaren amtlichen Grenzen sind? Das wäre sicher interessant zu erfahren.
Edbert (EvanE)
Ich habe mich an die Bayern gehalten, die haben die Auskunft erhalten (die ich juristisch spitzfindig gesagt nicht überprüft habe), dass die im Rahmen der Open_Data_Initiative freigegebenen Daten auch unter ODBL gestellt werden dürfen, auch dort unter Namensnennung an den Primärdaten in OSM.
Eigentlich muss dem jeder Lizenzgeber einzeln zustimmen. Aber hoffen wir mal das Beste. Ein positives Beispiel wie Bayern ist schon einmal ein Pluspunkt für uns.
Joachim (unser Mann für den Kontakt zu Behörden) wird das sicher in nächster Zeit klären.
Edbert (EvanE)
Falls jemand sucht, hier ist der passende Thread:
http://forum.openstreetmap.org/viewtopic.php?id=19766
Gruß,
Mondschein
Dass auf feste IDs verwiesen wird, überrascht mich etwas. “Harte” Referenzen würde ein Informatiker nie verwenden, da die viel zu verwundbar sind. Das ist wie ein Sprung an eine feste Adresse in einem Programm. Wer macht sich schon Gedanken, wenn er einen vermurksten Gebäudeumriss löscht und durch einen neuen “from scratch” (mit denselben tags) ersetzt?
Übrigens: Ich habe diese Vorgehensweise nicht erfunden, sondern vom Import der Infas-Kreisgrenzen sinngemäß übernommen. Der schien mir plausibel: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005
Das hängt ganz von der Qualität der alten Daten ab. Die Kreisgrenzen aus dem Infas-Import stimmen bis auf wenige Meter überein (die nodes liegen in der Regel etwas weiter auseinander). Die hätte man lassen können, ich habe nur aus Konsistenzgründen auch da die LGL-Daten verwendet, da dann Gemeindegrenzen und Kreisgrenzen (nodes & ways) in den entsprechenden Abschnitten identisch sind.
Woanders können die Abweichungen Dutzende Meter betragen. Dort oft auch note/FIXME “grobe Abschätzung” o.ä. Komplizierte Topografien (z.B. Exklaven) fehlen manchmal ganz.
Gut zu sehen mit Filter “boundary:admin OR obsolete_boundary:admin”.
Ich wollte dich nicht kritisieren, das Vorgehen vom Kreisgrenzen-Import zu übernehmen, ist durchaus sinnvoll. Ich wollte nur auf die nicht offensichtlichen Nebenwirkungen hinweisen.
Der Import der Infas-Kreisgrenzen und die dazugehörende Dokumentation fand 2008 statt (quasi in der OSM-Deutschland Steinzeit). Damals gab es nichts anderes als die ID der Relationen (welche selber recht neu waren). Diese Methode hat sich bis heute gehalten (auch unsere lokale Wiki-Seite enthält feste IDs).
Die Overpass-API und damit die Möglichkeit ein Objekt auch unabhängig von einer festen ID zu identifizieren, gibt es erst seit ungefähr einem Jahr (oder sind es bereits zwei?), Der Overpass-Turbo, mit dem man schnell eigene Auswertungen schreiben/entwickeln kann ist sogar erst von Anfang dieses Jahres.
BTW: Die Leute bei OSM sind eher Kartografen als Informatiker (auch wenn sich das nicht ausschließt).
Insgesamt im Detail viele Abweichungen aber beim großen Überblick keine groben Schnitzer, also eher erträglich.
Als kleines Goodie eine Overpass-Turbo Abfrage auf obsolete_boundary=administrative beschränkt auf die Kreisgrenzen (admin_level=6).
Wer mag kann ja damit mal rumspielen. Aber Vorsicht, da kommen sehr schnell, sehr viele Daten zusammen.
Edbert (EvanE)
Wirklich nicht?
http://www.openstreetmap.org/browse/way/206313966/history
http://www.openstreetmap.org/browse/way/206701724/history
http://www.openstreetmap.org/browse/way/208288618/history
tbc.
Mapnik wertet nur boundary=administrative und admin_level=* an Ways aus. Beides zusammen bringt Mapnik dazu, den Way auf der Karte als Grenze darzustellen.
Die entsprechenden Tags an Relationen sind für Mapnik nicht relevant; sie werden aber für andere Programme benötigt.
Gruss
walter
Asche auf mein Haupt …
Ist mir auf admin_level=6 reingerutscht. Wird entfernt.
Tagge die inneren ways auch auf obsolete_ um. Dann dürften die meisten Renderer nichts mehr anzeigen.
@seichter: Entfernst Du bitte auch noch die mehrfach übereinander eingetragenen Linien und Knoten? Beispiel:
http://www.openstreetmap.org/browse/way/207529163
http://www.openstreetmap.org/browse/way/208421719
Die Linien habe ich nicht gezählt, aber bei den Knoten sind es knapp unter 4000 (Zählung erfaßt je einen richtigen plus einen bis mehrere überflüssige).
Arbeitshilfe: http://toolserver.org/~mapjedi/nodes_seichter.osm
Danke.
PS. Einer der oben beispielhaft genannten Wege enthält auch noch type=boundary.
Danke für die Datei mit Duplikatpunkten. Damit war es ziemlich einfach, die doppelten Linien zu finden. Die müssten jetzt entfernt sein. Ich habe noch kein Werkzeug gefunden, um Duplikate anzuzeigen. Auch der OSM-Inspektor zeigt sie mir nicht an.
Der Validator von JOSM zeigt doppelte Linie und Knoten an.
KeepRight kann ebenfalls überlagerte Linien und Mehrfach-Knoten anzeigen. Dazu am besten alles andere abschalten, da dies sonst unter der Vielzahl möglicher Fehler untergeht.
HTH
Edbert (EvanE)
Jein. Keep right! zeigt in der Tat mehrfache Knoten, aber dann gleich alle. Wenn man wie hier nur an denen eines bestimmten Users interessiert ist, hilft das nur bedingt (man kann natürlich gezielt schauen, welche sich fadenartig an Grenzen entlang ziehen). Zudem scheinen die Update-Intervalle derzeit wieder etwas länger auszufallen. Für den JOSM Validator hingegen muß man die entsprechenden Daten erst einmal in JOSM laden, also entweder ganz BaWü (nicht) oder z.B. per Overpass-API oder Durchwühlen des Geofabrik-Extrakts sämtliche dortigen Grenzen. (Das würde ich zur Kontrolle aber dennoch empfehlen: ich habe zwar oben die doppelten Knoten aufgezeigt, aber falls es doppelte Wege gibt, die sich ihre Knoten teilen, kommen diese so nicht zum Vorschein.)
Generell zur Duplikatvermeidung: Wenn JOSM beim Hochladen zu klemmen scheint, nicht voreilig “Abbrechen” drücken. Wenn nämlich das aktuelle Paket bereits komplett zum Server geschickt wurde und nur die Bestätigung noch aussteht, entstehen beim nächsten Hochladeversuch die Duplikate. Und im Hochladedialog nicht die Einstellung “Daten in einer Anfrage hochladen” wählen, sondern “Objekte in mehreren Paketen hochladen” mit einer moderaten Paketgröße (100 ist eine brauchbare Größenordnung - bei einfachen Objekten auch mehr, bei komplizierten und großen Relationen oder brüchiger Internetverbindung weniger, aber 100 ist eine gute Standardeinstellung). Die Komplexität und Dauer einer Upload-Abfrage wächst mit der Anzahl der Objekte im Paket - und zwar bei wechselseitigen Abhängigkeiten nichtlinear.
PS: Doppelte Knoten in BaWü, Stand Geofabrik-Extrakt von heute (zeigt auch noch einige Doppelknoten an Grenzen - Filtern nach user:seichter): http://toolserver.org/~mapjedi/dupenodes_bw.osm.bz2 Ein großer Teil entfällt freilich auf die “Neue Universität Heidelberg” und weitere Hochschulgebäude a.a.O., wo einzelne User jedes Fenster etc. auf jeder Etage eingetragen haben. Es gibt aber auch echte Duplikate, etwa einige doppelte und dreifache Hydranten in Beulen an der Rinn Sontheim an der Brenz (zudem mit Adressdaten).
Richtig, für JOSM Validator müssen die Objekte geladen sein. Ich habe am Anfang nur in den Relationen unvollständige Elemente herutergeladen. Dann wurden Linienzüge ohne Warnung hochgeladen, selbst wenn der selbe in der Datenbank schon vorhanden war. Später habe ich dann wenigstens an “Dreiländerecken” heruntergeladen, dann sollte es eigentlich nicht mehr passieren. Ansonsten hat jedes der Tools seine Stärken und Schwächen, manches wird nicht erkannt, manchmal sind sie übereifrig.
Kann ich nur bekräftigen. Ohne Begrenzung lädt OSM bei größeren Datenmengen minutenlang zu OSM hoch und man weiß nicht, ist er noch am Hochladen oder hat er sich aufgehängt. Häufigeres Hochladen mit kleinerer Datenmenge ist sowieso besser, damit einen der Validator bei mangelnder Vorsicht nicht mit Warnungen und Fehlern überhäuft.
Grenzen müssten bereinigt sein, ein paar waren es schon (-> Aktualität der Daten). Bei der Gelegenheit habe ich die Mehrfach-Hydranten in Sontheim entfernt (es waren bis zu 4), dazu noch ein paar Hausnummern- samt Beinahe-Duplikaten (Grwenzweg) direkt daneben. Gruß an die Feuerwehr, die halt lieber mit mehreren Rohren gleichzeitig löscht 
Hallo,
an den alten Relationen ist zwar der boundary-Key umgenannt worden, aber die Keys de:amtlicher_gemeindeschluessel und de:regionalschluessel sind aktiv geblieben.
Das stört zwar nicht direkt die OSM-Straßenlistenauswertung [1], es kommen aber intern Warnmeldungen und das kann auch andere Auswertungsprogramme irritieren, wenn die nur diese Keys gehen würden. Die Keys (oder besser die alten Relationen komplett) sollten aus meiner Sicht zeitnah angepasst werden.
Viele Grüße
Dietmar aka okilimu