nachdem mit der OpenData-Initiative (http://vermessung.bayern.de/opendata) alle Grenzen von/in Bayern mit CC-BY als Shapefiles zur Verfügung stehen, frage ich mich, ob man die einmal in OSM einpflegen sollte.
Die derzeitigen Grenzverläufe sind ja teils sehr ungenau.
Dabei stellen sich mir ein paar Fragen:
Sollte man die Daten einfach hochladen und damit (vorübergehend) alle Grenzen doppelt haben (bis die ungenauen alle manuell gelöscht worden sind)?
Die Grenzen scheinen nicht alle aus einer Quelle zu stammen, sodass z.B. die Bezirksgrenzen nicht genau auf den Gemeindegrenzen verlaufen. Ist das wirklich so, dass die fast immer unterschiedlich sind, oder ist das einfach eine Ungenauigkeit? Kleinere Flächen (einzelne Grundstücke) sind auch öfter dem “falschen” Bezirk zugeordnet - das erscheint mir unlogisch.
Hat jemand schon Erfahrung mit dem hochladen von Grenzdaten auf Basis von vorhandenen Daten? Ideal wäre es, wenn das ein Bot erledigen könnte, den man alle paar Jahre mal wieder anwirft, um die Daten aktuell zu halten. Als Hauptproblem sehe ich das korrekte Löschen der veralteten Grenzen - hier könnte es aber vielleicht eine einfache Möglichkeit geben, alle Grenzen innerhalb Bayerns zu löschen (?) - und das Erstellen der Grenz-Relationen über den Gemeindegrenzen (Verwaltungsgemeinschaft, Landkreis, Bezirk, Bundesland).
Die Datenaufbereitung der Gemeindegrenzen aus dem Shapefile geht mit dem “ogr2osm.py”-Skript (http://wiki.openstreetmap.org/wiki/Ogr2osm), das man um “translations” erweitern kann, um die Attribute in OSM-konforme Tags zu übersetzen.
Ich finde es schon sehr störend, wenn man manche Grenzen mitten durch Siedlungen laufen sieht, die sicher nicht zu verschiedenen Gemeinden gehören. Da nun (ziemlich) korrekte Daten frei zur Verfügung stehen, denke ich, wäre es naheliegend, diese zu nutzen.
zunächst einmal: Ich habe mir den Grenzdatensatz nicht angeschaut. Angeblich sind die Grenzen “generalisiert” (d.h. ungenau); das koennte u.U. auch die von Dir beobachteten Probleme erklaeren.
Nein, man sollte nie irgendwas “einfach hochladen”, auch nicht diese Grenzen.
Das ist ein gutes Zeichen dafuer, dass dieser Grenzdatensatz nicht notwendigerweise in allen Belangen besser ist als das, was wir haben, und dass wir, statt diesen Datensatz hochzuladen und unseren wegzuwerfen, diesen Datensatz lieber als zusaetzliche Informationsquelle nehmen sollten, um unsere Daten zu pflegen.
Nein, auf keinen Fall. Wenn jemand wirklich genau diesen Grenzdatensatz benutzen will, dann soll er das tun - es ist zum Beispiel gar kein Problem, in Mapnik eine Regel einzubauen, die sagt “Grenzen nicht aus dem OSM-Datensatz einzeichnen, sondern aus diesem Shapefile”.
OSM ist ein Editiersystem. Was da hochgeladen wird, das kann und soll von Menschen bearbeitet werden und ganz gewiss nicht alle paar Jahre mal durch einen amtlichen Datensatz zweifelhafter Qualitaet ersetzt werden!
Das werden wir ganz bestimmt nicht tun, in unseren Grenzdatensaetzen steckt viel Arbeit. Du erwaehnst selbst die Grenzrelationen; zuweilen wird eine Grenze sich sicher auch an einer existierenden Geometrie orientieren (Fluss, Waldrand, Strasse) oder umgekehrt. Da muss sauber von Hand gearbeitet werden, da kann man nicht einfach einen Grenzdatensatz draufklatschen nach dem Motto “die haesslichen Stellen koennen die Mapper ja spaeter reparieren, ich mach jetzt erstmal den leichten Teil”.
Es gibt verschiedene Arten, wie man mit solchen Daten umgehen kann.
Moeglichkeit 1: Jemand bereitet einzelne OSM-Dateien mit Hilfe eines Skripts vor (z.B. eine pro Landkreis oder so), und Mapper koennen sich diese Dateien dann vornehmen und von Hand “einpflegen” und dabei alle Relationen usw. richtig machen. Diese Methode hat den Nachteil, dass es manchmal eifrige, aber schludrige Mapper gibt, die sich so ein Ding in JOSM laden und auf Upload druecken, ohne wirklich die erforderliche Handarbeit gemacht zu haben. Ausserdem ist diese Handarbeit manchmal verdammt schwer.
Moeglichkeit 2: Wir laden die Daten in einen WMS, so dass man sich das im Editor-Hintergrund anzeigen lassen und existierende Geometrien von Hand “zurechtzupfen” kann. Hier hat man zwar die Handarbeit des Geometrie-Nachmalens, aber man kann die existierenden Relationen unangetastet lassen - und “exakt” sind die Bayern-Datensaetze ja eh nicht, also spielt auch die Ungenauigkeit durch das “Nachmalen” keine Rolle. - Einen aehnlichen Weg haben wir vor langer Zeit mal mit Daten von “Strassen NRW” gewaehlt. Damals gab es sogar die Moeglichkeit, sich einzelne Linien, die in OSM noch gar nicht drin waren, auf Knopfdruck in den JOSM zu laden.
Moeglichkeit 3: Der “Snapshot Server” in Zusammenarbeit mit Potlatch. Das ist eine recht neue Entwicklung von Andy Allan; da konvertiert man die Daten in OSM-Format, laedt sie auf den “Snapshot Server” und kann dann mit Potlatch diese Daten zusaetzlich zu OSM-Daten sehen und auf Knopfdruck in OSM uebernehmen, und man kann sogar Daten auf dem Snapshot-Server als “erledigt” markieren. Das ist alles noch recht jung, aber wenn irgendwann mal jemand fuer JOSM die Unterstuetzung dafuer einbaut, dann wird das bestimmt eine verbreitete Art, mit freigegebenen Daten umzugehen.
Diesen Moeglichkeiten ist gemein, dass sie sich auf die Handarbeit von Menschen verlassen - in Gegenden, in denen sich niemand dafuer interessiert, werden die Daten auch nicht eingepflegt werden. Das ist aber eine Stärle und keine Schwäche dieser Moeglichkeiten - denn Daten, fuer die niemand bereit ist, ein bisschen Arbeit zu machen, sind “verwaist” in OSM, die liegen dann nur rum und verstauben.
Vermutlich gibt es noch weitere Moeglichkeiten. “Existierende Grenzen loeschen und neue hochladen” ist zwar eine technische Moeglichkeit, aber keine akzeptable.
Eben, und von Dingen, die man nicht angeschaut hat, sollte man nicht soviel quasseln
Kein Mensch kennt die Grenzen, deshalb sind wir quasi auf Spenden des Staates angewiesen. Ist halt nicht so wie bei Hausnummer, die ich selbst nachprüfen könnte.
Die Grenzen wurden auf “1:25000” generalisiert und haben etwa die Komplexität des “Kreisgrenzenimport 2005”. Unsere Gemeindengrenzen innerhalb eines Landkreises sind nicht selten
ungenauer, daher wäre eine Übernahme schon ein Verbesserung.
Einige Grenzen von uns wurden von Ablehner bearbeitet, auch aus dieser Sicht ein Gewinn!
Zuallererst muss aber die Lizenzfrage geklärt werden. (name vergessen) wollte sich nach Hl.Dr.Kö darum kümmern. First things first!
Die meiste Zeit habe ich von Imports im allgemeinen gequasselt, und davon habe ich nun wirklich sehr viele angeschaut.
Nutzen sollte man die Daten auf jeden Fall, bloss “übernehmen” halt nicht. Denn was kurzfristig eine Verbesserung auf der Karte bringt, entpuppt sich mittelfristig gern als schaedlich fuer die Pflege und Erhaltung.
Es geht mir hauptsaechlich darum, dass nicht irgendein Held denkt, er koennte mal eben so bayernweit die Daten importieren. Wenn die Leute wenigstens das verstehen, bin ich schon halb zufrieden.
Da stand doch CC-BY auf der Seite drauf. Und die Englaender benutzen ja auch ohne Zoegern deren Ordnance-Survey-Daten mit Attribution-Klausel. Wird also schon passen.
Also ich hatte und habe nie vor, größere (teilautomatisierte) Änderungen vorzunehmen, wenn ich mir nicht sicher bin, dass das auch nur vielleicht kontraproduktiv ist. Daher möchte ich auch hier über das Thema diskutieren.
Bezüglich Genauigkeit kann ich sagen, dass alle Grenzen in der Umgebung meines Wohnortes sehr genau sind (wenige Meter Abweichung) und die OSM-Grenzen sehr ungenau (nicht selten >1km Abweichung) waren (bis ich sie etwas genauer gemacht habe).
Zur Lizenzfrage: Da die OSM-Lizenz CC-by-SA ist, sehe ich kein Problem (CC-by ist freier und damit kompatibel zu CC-by-SA).
Das Argument, dass Grenzen “auf” Bächen verlaufen, verstehe ich und ist meines Erachtens der Hauptgrund dafür, dass man den Datensatz per Hand einpflegen sollte. Das habe ich zuvor nicht bedacht. Damit sehe ich es als hinfällig an, die Daten alle paar Jahre (teil)automatisiert zu importieren.
Im Folgenden sollten wir also noch darüber diskutieren, ob es Sinn macht, einmalig die Daten zu importieren oder nicht.
Ich fasse mal zusammen:
Dafür spricht, dass die Daten sehr genau und aktuell sind.
Dagegen steht das genannte Argument, dass Grenzen entlang von Landschaftselementen (typischerweise Bäche) die Assoziation verlieren und dass die bisherige Arbeit überflüssig wird (wobei man bedenken sollte, dass das in Wiki-Systemen normal ist).
Wenn es keine einfache Möglichkeit gibt, die Relationen zu Verwaltungsgemeinschaften, Landkreisen und Bezirken automatisch erstellen zu lassen, ist der arbeitsaufwand hierfür nicht viel kleiner, wie wenn man gleich alles per Hand macht (je die bisherige Grenze löschen und durch die importierte Grenze ersetzen).
Findet sich niemand, der so ein Skript erstellt, so werde ich den Datensatz der Gemeinden so gut wie möglich (Übersetzung der Tags) konvertieren und ins Wiki hochladen.
hast du dich schon mal intensiver damit beschäftigt, WIE Grenzen in OSM angelegt sind? Das ist nämlich nicht so trivial, wie man annehmen könnte.
Ich gehe mal davon aus, dass du pro “Lokalität” EINEN Datensatz oder ähnliches besitzt, der die jeweilige Grenze im Ganzen beschreibt.
Dann ist es nicht damit getan, verschiedene Datensätze zu Obereinheiten zusammenzufassen. Ganz im Gegenteil müssten sie in Tausende von Teilstücken (ways) aufgebrochen, vereinzelt und in Relationen zusammengefasst werden. Dies gilt auch für jede Grenze jedes Ortes, da dieser i.d.R. geschlossene Kreis nicht SO nach OSM importiert werden kann.
Weiterhin müssten die ALLE ANDEREN Admin-Level, die ja von 2 bis ca 11 gehen können, NAHTLOS eingebunden werden. Selbst die Grenzen der Umgebung von Bayern bis hin zu den Internationalen Landesgrenzen müssten berücksichtigt werden.
Das ist wirklich nicht einfach - ich möchte sogar behaupten: unmöglich.
Gruss
Walter
p.s. man beachte den Konjunktiv - das ist nur ein Gedankenspiel.
Fehlen denn noch irgendwo Gemeindegrenzen in Bayern?
Weil wenn nicht, würde es ja reichen, die Grenzen als Hintergrund z.B. für JOSM zu verwenden um vorhandene Grenzen zu korrigieren.
Ich würde mal unseren “Theoretikern” empfehlen, sich das ganze mal anzuschauen und danach rumquasseln.
Wie ich schon schrieb in “Erweitertes Open(Geo)Data-Angebot in Bayern”:
Beispiel:
shp2osm.pl Happurg.shp > Happurg.osm
liefert eine Gemeindegrenze als way mit 1701 Punkte (kann man von mir aus noch in 10 Teilstücke runterbrechen lassen).
Desweiteren:
Dinge der Unmöglichkeit sehen bei mir anders aus
Auch wenn ich kein Fan von “blindlings Importieren” bin
Ja, das ist mir schon klar, wie es realisiert ist.
Es ist sicher keine einfache Aufgabe, hierfür ein Skript zu basteln. Aber es könnte ja sein, dass das schon einmal wer gemacht hat und recht leicht anpassen kann. Ernsthaft gehe ich inzwischen nicht mehr davon aus (wobei die Relationen auf Gemeindeebene bereits nach der Konvertierung ins OSM-Format vorhanden wären, problematisch ist v.a. das Zusammenfassen mit den übergeordneten (VG, LKR, Bez,…) Grenzen).
Wie ich vorgehen würde, um den Datensatz manuell nach OSM zu übernehmen wäre folgende (ich verwende JOSM, alle anderen Editoren kenn ich nicht):
Ich konvertiere mit dem ogr2osm-Skript das Shapefile ins OSM-Format, das man mit JOSM öffnen kann. Wie erwähnt kann ich diese OSM-Datei ins Wiki (oder sonst eine website) hochladen, damit andere nicht auch erst das Shapefile umständlich konvertieren müssen.
Die OSM-Datei mit den Grenzen besteht nun, wie in den derzeitigen OSM-Daten auch, aus Grenz-Abschnitten, die über Relationen zu Gemeinden zusammengefasst sind. Zu jedem Grenzabschnitt der konvertierten Datei existiert normal dann auch ein Abschnitt im derzeitigen OSM-Datensatz. Damit ließe sich jeder Grenzabschnitt einzeln problemlos ersetzen.
Beispielhafte Vorgehensweise in JOSM:
Lade zum Editieren einen Ausschnitt von OSM herunter → Ebene A
Öffne das konvertierte Shapefile → Ebene B
Wähle einen Grenzabschnitt aus (in Ebene B) und kopiere ihn
Gehe zur Ebene A und füge dort den Abschnitt ein
Suche den entsprechenden bisherigen Grenzabschnitt und verbinde Anfang und Ende mit der eingefügten Linie (‘m’ und dann ‘c’)
Wähle im erscheinenden Dialogfenster die passenden zu übernehmenden Attribute (alle Relationen müssen normal behalten werden)
Trenne den entstandenen Ring wieder an den selben beiden Punkten auf und lösche den “alten” (ungenauen) Teil.
Das sind zwar schon einige Schritte, aber wenn man es ein paar mal macht, bekommt man schnell Routine. Und so viele Grenzen gibt es in Bayern auch wieder nicht (zumindest im Vergleich zu Straßen).
Die Grenzen als Hintergrund zu verwenden halte ich für nicht so effektiv, da es meist nicht weniger Aufwand ist (jeder Punkt müsste einzeln übernommen werden) und zudem kleinere Ungenauigkeiten entstehen, oder manche Punkte vergessen werden.
Danke für den Hinweis. Eigentlich dachte ich schon, das musste doch schon mal diskutiert worden sein, aber per Suchfunktion kam ich da irgendwie nicht hin.
Nachdem dort auf die Zeit nach Dreikönig verwiesen wird, würde ich auch sagen, erst mal abwarten.
Der way für die gesammte Gemeinde muss aufgebrochen werden, damit man jeweils die Teilstücke zwischen den Gemeinden hat.
Da die Gemeinden natürlich Rand an Rand liegen, müssen doppelte Ways entfernt werden.
das sich so ergebene Netz aus AL-6-ways muss nochmals mehrfach aufgetrennt werden, da von den ALTEN AL-6-Ways natürlich auch höhere Level abzweigen
es müssen die AL-6-Ways entfernt werden, die Bestandteil bestehender AL 2-5 sind.
u.s.w. u.s.w.
unter Anderem “teilen” sich die Grenzrelationen auch noch sehr viele ways mit den PLZ-Gebieten oder deren Member sind einfach “normale” ways (Flüsse/Strassen/Tracks/…)
Wie kellerma im Laufe dieses Threads schrieb sind die Grenzen auf den Maßstab 1:25000 generalisiert. Mit anderen Worten ein Millimeter entspricht 25 Meter in der Natur.
Wenn man das beachtet sind die Daten eher eniger genau als das, was in OSM bereits existiert. 10 Meter und besser kriegen wir in OSM meist problemlos hin.
Verabschiede dich bitte von der Vorstellung, dass amtliche Datensätze präzise und akurat sein müssen. Das einzige was man sicher annehmen kann, ist dass sie zum Zeitpunkt der Veröffentlichung in der Regel schon wieder veraltet sind.
Also nimm die Daten zum Vergleich (sprich als Hintergrund), vor allem da, wo wir wissen, dass unsere Daten nur geschätzt sind. Aber stelle sie nicht über das, was bereits erfasst ist.
Zwecks Kontrolle der bereits in OSM vorhandenen Gemeindegrenzen auch für admin_level größer als 6 gibt es eine recht simple Lösung via osmfilter und JOSM:
