Nutzungsbedingungen: “Vervielfältigung und Verbreitung, auch auszugsweise, mit Quellenangabe gestattet.”
Darf ich die Daten für einen Vergleich mit den OSM daten nutzen um fehlende Grenzen zu finden oder Rechtschreibefehler zu finden ?
Gibt es jemanden der sich mit einer regelmässigen automatisierten Kontrolle (also einem Bot) in dem Bereich schon beschäftigt, also z.B. einheitliche Schreibweise, Leerzeichen löschen, Rechtschreibfehler korrigieren, fehlenden Regionalschlüssel ergänzen etc.
Immer mehr werden ja auch schon Stadtteile und Ortteile unterhalb der Gemeinde Ebene gemappt, die haben ja auch immer amtliche Nummern, die man meist bei den statistischen Ämtern der Länder bekommen kann. Dafür scheint es aber noch kein erkennbares Taggingschema zu geben, wohl bisher nur einen Vorschlag: http://wiki.openstreetmap.org/wiki/DE:Amtlicher_Gemeindeschl%C3%BCssel
gibt es da noch weitere Ideen ?
Mit den Rechtschreibefehlern meine ich jetzt alleine die Gemeindeschlüssel und Regionalschlüssel Nummern … ich nehme einfach mal an dass die in der amtlichen Liste vom Bund auch korrekt sind.
Mit Fehler meinte ich eine einheitliche Schreibweise ( also z.B einheitlich ohne Leerzeichen) und offensichtliche Schreibfehler wie Zahlendreher, vergessene Ziffern, oder Buchstabe statt Zahl oder eben einfach eine falsche Nummer
Was ich mittlerweile schon habe: Eine DB mit den alle 4 Monaten aktualisierten amtlichen Daten (daher meine Frage ob ich die auch offiziell für einen Abgleich verwenden kann), eine täglich aktualisierte DB mit den entsprechenden Grenz Relationen in der OSM Datenbank.
Ich kann Listen ausgeben, mit fehlenden Gemeinden, mit falschen Nummer, Rechtschreibefehlern, kann die OSM Daten überprüfen ob die Relationen geschlossen sind, also täglich aktualisierte Listen mit nicht geschlossenen Relationen, könnte automatisiert den Regionalschlüssel ergänzen etc.
Ja. Zur Kontrolle kannst Du im Prinzip benutzen, was Du willst; kritisch wird es immer erst bei der Übernahme von Daten - die in diesem Fall (mit Quellenangabe) sogar auch zulässig wäre.
Der User xylome läßt täglich seinen xybot auf diverse Tippfehler, Leerzeichen usw. los, aber nicht speziell auf Grenzen und die besagten Schlüsselnummern. Möglicherweise wäre er bereit, xybot entsprechend zu erweitern, oder kann anderweitig weiterhelfen. Frag ihn doch einfach mal. Falls Du vorhast, selbst einen Bot zu konstruieren, der also auch automatische Bearbeitungen vornehmen soll, sei auf http://wiki.openstreetmap.org/wiki/Automated_Edits verwiesen. Sicherer (und weniger kontrovers) wäre, nur mit einem Programm nach (möglichen) Fehlern zu suchen, und diese dann manuell zu beheben.
Das sollte grundsätzlich machbar sein, aber auch da: größte Vorsicht, mit “offensichtlich” kann man manchmal danebenliegen. Vielleicht solltest Du zunächst einmal prüfen, wie häufig solche Fehler sind, und ob sich ein Bot-Einsatz überhaupt lohnen würde. Je nach Ergebnis ist es evtl. sinnvoller, gerade für einen einmaligen Lauf einen der erfahrenen Bot-Betreiber ins Boot zu holen, statt das Rad neu zu erfinden, siehe den Hinweis auf xylome oben. xybot macht ja u.a. bereits verschiedene Textersetzungen, zuverlässig und annähernd fehlerfrei.
Es gibt wohl divere Auswertungen zu dem Thema, und auch der OSMI hat eine entsprechende Ansicht, aber eine derart komfortable Möglichkeit zur QS von Grenzen wie die AGS-Auswertung von Sven kenne ich aktuell leider keine. Ohne einen effizienten Workflow war mir das aber zu mühsam, dementsprechend bin ich hier auch momentan nicht mehr aktiv.
Da er ja anbietet, seine Skripte an Interessierte weiter zu geben hatte ich ihn einmal kontaktiert, musste aber schnell einsehen, dass so etwas aufzusetzen jenseits meiner Möglichkeiten liegt.
Den Workflow habe ich eigentlich für mich hier eigentlich gut im Griff, alle 3 Monate importiere ich die aktualisierte Liste vom Bund, meine OSM DB nur mit den entsprechenden Grenzrelationen wird momentan täglich automatisch aktualisiert. ich kann mir dann Listen ansehen was täglich an den Daten geändert wurde, wo eine AGS geändert wurde die nicht mehr mit der offiziellen übereinstimmt, wo eine Relation nicht mehr geschlossen ist, wo eine Relation evt. gelöscht wurde und wo eine neue Grenzrelation evt erstellt wird. Das ganze funktioniert eigentlich ohne großes Eingreifen.
Ich müsste das ganze jetzt nur noch in eine ansprechende Webform bringen …
Dann mache ich mich mal an die Arbeit … die Genehmigung zum Abgleich steht ja auch im WIKI, der Abgleich mit den amtlichen Daten sollte dann ja kein Lizenzproblem sein.
Wie sieht es denn mit einer europaweiten Klassifizierung aus ?
Ah, Du bist mir schon wieder einen Schritt voraus Ja, bei diesen Zahlen macht ein Bot-Einsatz Sinn. Ich würde spontan vermuten, daß die jeweilige Schreibweise meist seit Version 1 unverändert ist, richtig? In dem Fall sollte ein einmaliger Lauf ausreichen.
Bliebe nur zu klären, welche Schreibweise “richtig” ist… Da die Länge der Blöcke eindeutig ist, erfüllen Leerzeichen keine wichtige Trennfunktion, sondern scheinen eher der besseren Lesbarkeit zu dienen. Beim Statistischen Bundesamt finde ich die Schreibweise ohne Leerzeichen.
Die Schlüsselbeschreibung des Gemeindeschlüssel ist ja eindeutig, daher bietet sich die Schreibweise ohne Leerzeichen an wie sie ja auch überwiegend verwendet wird, eine einheitliche Schreibweise erleichert eben immer die automatische Auswertung.
ich vermute ja mal dass die Daten irgenwann mal per BOT importiert wurden. Was ich ja schon öfter mal anmerke ist, dass die Daten dann mit der Zeit verändert werden. Sie waren also vermutlich beim import korrekt, dann kamen langsam Fehler rein, warum auch immer, denn eigentlich müsste man den tag ja nicht mehr ändern, solange er sich auch amtlich nicht ändert.
Nicht übel. Als Ergänzung wäre vielleicht noch eine Flächenberechnung interessant. Zum einen, wenn sich die Fläche ändert, kann dies an einer unbeabsichtigten Verschiebung oder sonstigen Änderung der Grenze liegen (die anderweitig nicht auffällt); zum anderen könnte man die berechnete Fläche mit dem “offiziellen” Wert abgleichen (bei einheitlicher Berechnungsmethode), um mögliche Fehler in den Grenzverläufen zu entdecken. Letzteres ist allerdings eher Zukunftsmusik, solange wir noch jede Menge “gefühlte” Grenzen in der Datenbank haben…
Naja, man könnte auch argumentieren, daß beide Schreibweisen akzeptabel sind, und eine Anwendung eben bei Bedarf die Leerzeichen entfernen muß, à la sed ‘s/ //g’. Ich habe nichts gegen eine Vereinheitlichung, von mir aus können die Leerzeichen gerne weg - aber irgendwer wird sich fast sicher beschweren, da wäre eine “amtliche Definition” doch ein besseres Argument als allein die relativen Häufigkeiten beider Schreibweisen.
Prima Idee … die Flächen stehen ja im amtlichen Gemeindeverzeichnis. Könnte man ja z.B dann auf der Auswertungsliste farbig markieren wenn die Werte zu weit voneinander abweichen und sich das dann mal näher ansehen.
Ich werte die Gemeindeschlüssel für die OSM-Straßenlistenauswertung aus.
Die Gemeindeschlüssel kommen für meine Auswertung relevant hier vor:
an den Grenzrelationen als de:amtlicher_gemeindeschluessel
an den place-Objekten der Gemeinden selbst als openGeoDB:community_identification_number
Die falschen Schreibweisen sind eigentlich nur
falsches Format xx x xx xxx, so wie in wikipedia bei der jeweilgen Gemeinde angegeben
hintere 0en nicht vorhanden, also z.B. 0671 statt 06710000 (fiktives Beispiel)
Ich habe diese Schreibweisen in meiner Auswertung korrigiert, weil ich niemanden bevormunden möchte und es keine feste Formatvorabe gibt.
Früher hatte Florian Lohoff den is_in-bot in Aktion, der an den administrativen Elementen Änderungen vorgenommen hat. Leider sind die Änderungen von seinem nicht explizit zugelassen worden für den Lizenzwechsel.
Wenn ich falsche Gemeindeschlüssel gefunden hatte, habe ich sie korrigiert, allerdings sind nicht alle Fehler beseitigt, weil ich keine Vergleichsliste verwendet habe.
In Mecklenburg-Vorpommern wurden die Kreise reformiert und alle Gemeindeschlüssel neu vergeben (früher 1305xxxx und 1306xxxx, heute 1307yyyy). An den Grenzrelationen wurde die Änderung händisch von einem OSM-ler durchgeführt, an den place-Knoten ist Umstellung erst zur Hälfte durchgeführt worden.
Wenn jemand einen Bot schreiben möchte, hätte ich noch folgende Wünsche:
Prüfung der is_in Struktur. In Mecklenburg-Vorpommern ist da noch vieles falsch. In Rheinland-Pfalz fast alles, weil dort vor einigen Jahren die Regierungsbezirk-Ebene abgeschafft wurde, die aber überall noch enthalten sind.
für eine graphische Auswertung in JOSM (nach osmfilter!) könnte man auch das Beispiel unter http://wiki.openstreetmap.org/wiki/MapCSS/Examples so anpassen, dass statt dem admin_level der Wert von de:amtlicher_gemeindeschluessel ausgegeben wird.
So könnte man schon optisch irgendwelche Lücken oder doppelte Daten in den Gemeindegrenzen und den Schlüsselzahlen erkennen.
Das mit der falschen Schreibweise ist eine reine Definitionsfrage, schliesslich hat der Gemeindeschlüssel (oder auch AGS) einen wohldefinierten Unteraufbau (http://de.wikipedia.org/wiki/Amtlicher_Gemeindeschl%C3%BCssel), der sich durchaus mit den Leerzeichen anzeigen läßt (und damit für den Menschen schneller verifizieren läßt). Auch die fehlenden Nullen sind legitim (auch wenn Dein fiktives Beispiel a) um eine Stelle zu kurz ist und b) in Hessen (06) kein Regierungsbezirk mit dem Wert 7 existiert), denn wenn Dein Beispiel z.B. 06 4 31 gewesen wäre, dann wäre es als Kreis Bergstraße identifizierbar gewesen.
Diese Hinweise würden dann auch in die nicht existierende Wiki-Seite zu diesem Key gehören.
Und wo ich gerade mit Haarspalten bin: Die Schreibeweise de:amtlicher_gemeindeschluessel müsste eigentlich DE:amtlicher_gemeindeschluessel lauten, da Ländercodes im Gegensatz zum Sprachcode gross geschrieben werden. Als Alternative empfehle ich ein wesentlich kürzeres ref:ags und da es in Österreich ebenfalls ein AGS existiert mit der Schreibweiseref:ags=<Ländercode>:. Dann könnte man auch direkt die 204 de:amtlicher_regionalschlüssel mit verarzten.
Nun genau diese “Definitionssache” ist ein ernstes Problem bei OSM. Denn es gibt kaum eindeutige Definitionen. Im Grunde sollte es doch ein leichtes sein, einfach festzulegen: die 8 Ziffern werden ohne Leerzeichen geschrieben. Wie man die später anzeigt ist dann Sache der Auswerter, es ist aber eben einfacher ein einheitliches Format weiter zu verarbeiten.
Aber was spricht dagegen, die für den Menschen einfacher zu lesende Schreibweise mit Leerzeichen als Standard zu definieren? Zahlen mit mehr als vier Stellen ohne Unterteilung sind für Menschen recht unhandlich. Z.B. sollen daher Telefonnummern nach DIN in Zweier-Blöcken geschrieben werden.
Leerzeichen zu ignorieren sollte für ein Programm doch etwas sehr einfaches sein.
Den Vorschlag von Georg das besser als ref:…=<Ländercode>: zu erfassen, kann ich nur unterstützen. Allerdings würde ich ref:cin=<Ländercode>: vorschlagen. Siehe dazu den Artikel Amtlicher Gemeindeschlüssel in der englischen Wikipedia.
Nichts spricht dagegen. Oft wird im Forum die Anzahl der Tags mit einer bestimmten Schreibweise als Argument genannt.
Aktuell wird de:amtlicher_gemeindeschluessel 12226 x verwendet und davon nur 1262 x mit Leerzeichen
Also würde ich jetzt mal darauf schließen, dass man es so vereinheitlichen sollte wie es in der überwiegenden Mehrzahl gemacht wird.
Aber auch das ist nebensächlich. Wegen mir könnte man es auch mit Leerzeichen machen oder auch gleich ein eigenes Schema, in dem man auch noch den Regionalschlüssel mit abbilden könnte.
Aber das wichtigste: kann man sich nicht einfach auf eine Schreibweise einigen?
Dazu wäre als erstes eine Dokumentation des Schlüssels im Wiki sinnvoll.
Da sollte dann rein:
wofür das überhaupt gut ist,
dass es zwei verbreitete Schreibweisen gibt und
dass es einen Vorschlag gibt, dies international zu vereinheitlichen.
Zu letzterem sollte man dann noch ausführen, dass der Wertebereich und das Format spezifisch für die einzelnen Länder ist.
In dem Rahmen sollte man einen Vorschlag für eine Standard-Schreibweise machen.
Da a) verschiedene Länder unterschiedliche Strukturen haben und b) ein Trennzeichen die Struktur leicht erkennen lässt, halte ich ein Leerzeichen als Strukturtrenner weiterhin für sinnvoll. Schließlich sind es Menschen, die diese Informationen eintragen und kontrollieren.
Ja, bei diesen Zahlen macht ein Bot-Einsatz Sinn. Ich würde spontan vermuten, daß die jeweilige Schreibweise meist seit Version 1 unverändert ist, richtig? In dem Fall sollte ein einmaliger Lauf ausreichen.