Gemeindegrenzen Bayern - Wochennotiz Nr. 122

Communities Deutschland (Germany)
21

Hallo Franz,

stimmt, Deine Angabe habe ich auch auf meinem Windows Rechner gesehen (der mit GDAL 1.9.1) und es wird nur die Authoritäts-ID USER:100000 angegeben , während ich unter Ubuntu

+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs

was der Definition “DHDN / Gauss-Kruger zone 4” und Authoritäts-ID “EPSG:31468” in den vordefinierten Referenzsystemen der Welt steht.

Die shape.prj Datei ist
PROJCS[“DHDN_3_Degree_Gauss_Zone_4”,GEOGCS[“GCS_Deutsches_Hauptdreiecksnetz”,DATUM[“D_Deutsches_Hauptdreiecksnetz”,SPHEROID[“Bessel_1841”,6377397.155,299.1528128]],PRIMEM[“Greenwich”,0.0],UNIT[“Degree”,0.0174532925199433]],PROJECTION[“Gauss_Kruger”],PARAMETER[“False_Easting”,4500000.0],PARAMETER[“False_Northing”,0.0],PARAMETER[“Central_Meridian”,12.0],PARAMETER[“Scale_Factor”,1.0],PARAMETER[“Latitude_Of_Origin”,0.0],UNIT[“Meter”,1.0]]

und entspricht welchem der beiden?
Interpretiert QGIS hier in einem der Fälle falsch und liegt das an den unteschiedlichen GDAL/OGR Versionen, die darin kompiliert sind oder geht das in die Richtung [1] als Ursache?

Wenn die Sven-Transformation am genauesten ist, nehme ich die zur Konvertierung, stimmts?
Viele Grüße

Dietmar aka okilimu

[1] http://hub.qgis.org/issues/4977

22

Hallo Dietmar,

anscheinend wertet die verwendeten QGis-Versionen die shape.prj unterschiedlich aus. Die verwendete Windows-Version ermittelt offenbar aus den Angaben dort die Parameter, die für die Umrechnung in das WGS84-Ellipsoid benötigt werden (towgs84) und die sich mit den „offiziellen‟ Quellen decken, während die Ubuntversion das nicht macht. Allerdings hat bei mir EPSG:31468 auch andere Parameter:

+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=582,105,414,1.04,0.35,-3.08,8.3 +units=m +no_defs

Mein Fazit ist:

Die Koordinaten mit der verwendeten Windows-Version von QGis und der NTv2-Transformation von Sven sind im Prinzip gleichwertig, aber wenn wir schon die Möglichkeit haben, auf die genauere NTv2-Version zurückzugreifen, sollten wir diese verwenden.

Viele Grüße
Franz

23

Hallo,

der

wird bei QGis vergeben wenn eine Projektion verwendet wird, die QGis nicht drin hat.

sowohl Gauss-Krüger als auch WGS84 kennt aber QGis.

Man findet diese mit Hilfe des EPSG-Codes. Diese sind eindeutig. Die bei uns in Brandenburg verwendete EPSG-Variante kennt QGis nicht, da sie nicht in der EPSG-Datenbank steht. Hier wird Authoritäts-ID USER:10000x vergeben.

Gauss-Krüger:

“DHDN / Gauss-Kruger zone 4” mit Authoritäts-ID EPSG:31468
“DHDN_3_Degree_Gauss_Zone_4” mit mit Authoritäts-ID EPSG: 31464

beides ist im Prinzip dasselbe. Nur der Name unterscheidet sich. EPSG 31464 ist mit deprecated (veraltet) gekennzeichnet. Man soll also
“DHDN / Gauss-Kruger zone 4” mit Authoritäts-ID EPSG:31468
verwenden.

So. genug Koordinatengeschichten… :slight_smile:

Sven

24

Hallo,

ich will die Daten neu jetzt auf Basis der von Sven konvertierten Datei bereitstellen.

In der ersten Version waren die Gemeinde-Relationen als

  • type=multipolygon

gesetzt gewesen, weil vom Programm so automatisch erstellt und von mir nicht angepasst worden.

Soll ich jetzt im zweiten Anlauf

  • type=boundary (statt type=multipolygon)
  • admin_level=8 (bis jetzt nicht vorhanden)
    setzen, dann wäre es kompatibel zu den bestehenden Grenzen?

Oder so lassen, damit hoffentlich keiner auf die Idee kommt, die Daten einfach 1:1 hochzuladen?

Viele Grüße

Dietmar aka okilimu

25

Hallo Dietmar,

ich würde vorschlagen “Multipolygon” zu verwenden, wenn die Grenze übernommen wird, sollte man Sie dann als boundary labeln.
Die Bearbeitung ist aus meiner Sicht einfacher, wenn sich die Grenzen “erstmal” am Type unterscheiden.

ludwich

26

Wie soll die Grenzrelation dann endgültig getagged werden? Als type=boundary oder type=multipolygon? Mir wäre aus grundsätzlichen Gründen type=boundary sympathischer. Bei der Typisierung von Relationen wird mit der Verwendung des Typs Multipolygon nach meiner Meinung inhaltliche und rein geometrische Typisierung unzulässig vermischt, aber das ist schon mehr eine Grundsatzfrage. Für die Typisierung sollte der Inhalt Vorrang haben. Erst in zweiter Linie sollte durch durch eine geometrische Kategorie angezeigt werden, welche Art von geometrischen Elementen in der Relation enthalten sind bzw. enthalten sein dürfen , Knoten, Wege, einfache Polygone (also geschlossene Flächen), Multipoygone oder eine bestimmte Kombination von Geometrien. Bei Grenzen ist ein einfaches Polygon ja die Regel, aber bei Verwaltungseinheiten mit Ex- oder Enklaven liegt ein Multipolygon vor.

Wie ist ist es mit der Angabe des admin_level bei den einzelnen Grenzabschnitten? Eigentlich ergibt sich dieser erst im Kontext der Relation, je nach dem ob der Abschnitt sich in einer Grenzrelation für Gemeinden, Landkreise, Regierungsbezirke etc befindet. Die im Wiki empfohlene Angabe des höchsten Level der beteiligten Relationen und die Begründung dafür ist für mich schon in der Nähe des in weiten Kreisen verpönten taggens für den Renderer.

Eventuell vielleicht die Quellenangabe trennen in source und source:url?

Gruß
Franz

27

Ist eine sinnvolle Regel für alle Anwendungen die mit der korrekten Relationsauswertung Probleme haben. Selbst unser
Standard Mapnik kriegt das noch nicht sauber hin. Der malt die Grenzen umso fetter in je mehr Relationen sie stecken.

Chris

28

Hallo Franz,

Die Wegabschnitte sollen ja in die vorhandenen Relationen übernommen und die dort noch vorhandenen, ungenaueren Wegabschnitte ersetzen.

Daher ist es eigentlich egal, welchen Typ die Relation selbst hat. Zur Unterscheidung werde ich type=multipolygon lassen im Sinne von Ludwich, das die Relation unterscheidbar bleibt. Dann finden wir auch evtl. doch mal eine übernommene Relation einfacher.

Die einzelnen Wegabschnitte habe ich mit boundary=administrative plus admin_level=8 getaggt. Das ist der Normalfall und sollte vom jeweiligen Importierer ggfs. angepasst werden.
Wenn eine Gemeindegrenze gleichzeitig auch eine Kreisgrenze ist, hat sie halt eine größere Bedeutung, also ist dann admin_level=6 schon richtig und nicht für den Renderer gedacht, sondern ein Fakt.

Die source möchte ich zusammen lassen. So ist der Kennzeichnungshinweis auf der Website vorgesehen. Neben der Relation trägt auch jeder Wegabschnitt das source-Tag. Das macht zwar mengenmäßig was aus, finde ich aber wichtig, weil so langfristig jeder Mapper noch herausfindet, wo die herkam.

Ich werde auf Wiki-Seite (danke für Erstellung, MetiorErgoSum) noch einige Besonderheiten für Ex- und Enklaven schreiben, wie die in den bereitgestellten Daten vorliegen, da ist etwas nachzuarbeiten.

Viele Grüße

Dietmar aka okilimu

29

Eine Abweichung in dieser Größenordnung tritt auf, wenn ohne die Bundeseinheitliche Transformation für ATKIS® (BeTA2007) transformiert wird.

Eine Beschreibung findet sich im Blog von Sven Geggus:
http://blog.gegg.us/2009/07/geodatenkonvertierung-fur-openstreetmap/

30

Gruß ludwich

31

Ihr könnt’ für Bayern
potsdam “towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58” “Germany (West - South - 47d00N to 50d20’N)” “Accuracy <1m”
verwenden, ist auch nicht viel schlechter als ntv2.
Kann gut sein, dass hinter dem “Ubuntu-potsdam” noch ein alter Wert rumgammelt,
vgl. auch http://forum.openstreetmap.org/viewtopic.php?id=12723

Desweitern möchte ich zu bedenken geben, dass die Grenzen generalisiert wurden, stimmen also sowieso nicht auf den cm.

32

Hallo,

ich habe heute vormittag die korrigierten Gemeindegrenzen neu zum herunterladen [1] bereitgestellt.

Bitte vor Arbeitsbeginn den Landkreis auf der Wiki-Seite [2] kennzeichnen, wo Ihr aktiv werdet, damit doppelte Arbeiten verhindert werden. dort gibt es auch hilfreiche Informationen über die Daten und wie sie zu integrieren sind.

Nimmt bitte die schon in OSM vorhandenen Grenzrelationen und ersetzt darin die einzelnen Wegabschnitte durch den genaueren Verlauf der jetzigen Dateien. Bitte nicht die darin enthaltenen Grenzrelaationen als ganzes übernehmen.

Viel Spaß und Erfolg wünsche ich uns,

Dietmar aka Okilimu

[1] http://regio-osm.de/bayern/opendata/gemeindegrenzen
[2] http://wiki.openstreetmap.org/wiki/Bayern/Gemeindegrenzen-OpenData-Initiative

33

Hallo,

mir ist es im Prinzip egal, ob und wie die Wege der einzlnen Grenzabschnitte in Relationen verarbeitet werden, da ich mir für JOSM folgende Arbeitsweise zurechtgelegt habe:

Ich lade mir die neuen Grenzen in eine neue Ebene und vereinige dann Abschnitt für Abschnitt mit der Arbeitsebene und nehme mir nach und nach die beteiligten Relationen vor (es sind ja unglücklierweise auch noch die Postleitzahlen beteiltigt), tausche dort die Wege aus und passe ggf. admin_level an. Dazu dazu ist unerheblich ob es eine boundary- oder eine deren Name nicht genannt werden darf-Relation ist. Eigentlich bräuchte ich gar keine Relation.

Wichtig wäre mir nur, dass bei jedem Grenzbschnitt die Attribute boundary=administration, admin_level=8 und das source-Attribut angegeben sind, das erspart Tipparbeit.

Grüße an Alle
Franz

34

Die neuesten Daten scheinen perfekt ausgerichtet, soweit ich es anhand einiger Stichproben im Vergleich mit dem Bayernatlas feststellen kann.

Demnach neige ich dazu, auch die Kreisgrenzen durch die neuen Bayern-Daten zu ersetzen. Weiter oben in der Grenzhierarchie wären wir dann bei den Grenzen Deutschland/Österreich usw., die ebenfalls an Genauigkeit gewinnen könnten. Hat jemand eine Meinung oder Tipps dazu: ersetzen oder lieber nicht anfassen?

35

Hallo MetiorErgoSum,

ich habe leider Deinen Vornamen wieder vergessen, sorry.

Die Kreisgrenzen innerhalb Bayerns ersetze ich in den LKs, die ich bearbeite.

Ob die Staatsgrenze schon genau vorliegen oder mit den neuen Daten genauer, habe ich nicht geprüft.

@Franz: Du hast doch, glaube ich, an der tschechischen Grenze Gemeindegrenzen angepasst. Wie bist Du da vorgegangen und welchen Eindruck hattest Du von der vorhandenen Staatsgrenze?

Viele Grüße

Dietmar aka okilimu

36

Wenn ich damit gemeint bin, das stimmt nicht. Aber grundsätzlich: Die Gemeindegrenzen sind das genaueste, was wir derzeit haben. Die Grenzverläufe an den Bundesländer- und Staatsgrenzen sind mit den dortigen Gemeindgrenzen prinzipbedingt identisch. Der Austausch an sich ist ja auch kein Problem. Nur die Überprüfung, ob danach die gesamte Grenzrelation in Ordnung ist, könnte etwas aufwändiger sein, das hab ich noch nicht probiert. Aber wenn sich der neue Grenzabschnitt lückenlos in die Aussengrenze im Bereich der Bearbeitung einfügt (mindestes ein Abschnitt vor-und nachher), könnte man in erster Näherung davon ausgehen, dass es in Ordnung ist. Die endgültige Überprüfung der Außengrenzen könnt man in gewissen Zeitabständen vornehmen. Oder man bearbeitet die Außengrenzen Bayerns vorrangig.

Grüße an alle
Franz

Nachtrag: Natürlich sollte man in Erfahrung bringen, aus welchen Quellen die Grenzverläufe der Nachbarländer stammen, ob die etwa noch genauer als die Bayerischen sind.

37

Dann mache ich das bei den Kreisgrenzen ebenso. Auf der Wikiseite habe ich dementsprechend Einträge für die kreisfreien Städte in der Arbeitsliste ergänzt.

Das Problem mit den Staatsgrenzen ist halt, dass es nicht nur die deutsche, sondern auch die österreichische/tschechische Grenze ist. Schon aus diplomatischen Gründen sollte man sich da vielleicht in größerem Kreis abstimmen, bevor man etwas ändert. Rein technisch scheinen die neuen Daten ein Gewinn zu sein: Stichproben an der Grenze Oberallgäu/Österreich zeigen, dass die Detailgenauigkeit steigt und die Lage entlang der Flussmitte einwandfrei passt.

Detlef, aber ich empfinde es nicht als unhöflich, mit meinem Usernamen angesprochen zu werden. Aufgrund ausgeprägter Datenkraken-Paranoia versuche ich immer, eine Verknüpfung zwischen meinen Rollen in unterschiedlichen Interessensgebieten möglichst zu erschweren. :wink:

38

Weil ich via E-Mail darum gebeten wurde, habe ich eine kurze Anleitung für Einsteiger auf die Wikiseite geschrieben. Wenn jemand effizientere und/oder besser für Einsteiger geeignete Methoden hat, wäre ich für Hinweise dankbar.