Gemeindegrenzen Bayern - Wochennotiz Nr. 122

Communities Deutschland (Germany)
1

Liebe Mittmapper,

bitte mit der Verwendung der mit https://lists.openstreetmap.de/pipermail/augsburg/2012-November/000642.html zur Verfügung gestellten Daten noch etwas warten. Ich habe Diskrepanzen in den Koordinaten zwischen diesen und meinen Daten aus gleicher Quelle festgestellt. Ich vermute einen Fehler bei der Koordinaten-Konvertierung bei der einen oder ander Seite und habe den Autor zur Klärung bereits angeschrieben.

Wenn die Abweichungen auch gering sind, wäre es doch schade, wenn falsche Daten in der OSM-Datenbank landen würden bzw. mit großem Aufwand nochmal korrigiert werden müssten.

Viele Grüße
Franz

2

Hallo,

bestimmt der berühmt-berüchtigte Lageversatz (ca 150-200m) von Daten, die aus dem Gauss-Krüger kommen. Bei solchen Sachen immer Datumsübergang beachten und beim Export entsprechende Transformationsmethode einstellen.

Sven

3

Den Kontakt hast Du erfolgreich hergestellt :wink:

Wenn Du selbst Konvertierungen von GK(4 oder allgemein) nach osm durchführst: kannst Du die eingesetzten Programme schildern?

An Alle: ich habe ogr2osm [1] (dort die Variante in OSM-SVN) eingesetzt, das in einem Schritt sowohl die Transformation als auch die Shape → OSM Konvertierung vornimmt. Es geht um eine konstante Abweichung von ca. 3,6 bis 4,0m.

Viele Grüße

Dietmar aka okilimu

4

Halllo Dietmar,

offenbar hast Du meine Mail über Adresse der Mailingliste noch nicht erhalten, da ich dort nicht angemeldet bin.

Mein Vorgehen war folgendes:

  • öffnen der heruntergeladenen Shape-Datei in QGis
  • Auswahl der benötigten Objekte
  • speichern der Auswahl als Shape-Dateien; dabei WGS84 als KBS angegeben
  • öffnen dieses Shapes in JOSM
  • Anpassung der Atrribute und trennen des Polygons in einzelne Abschnitte
  • speichern als osm-Datei
  • sukzessiver Austausch der Grenzabschnitte in den beteiligten Relationen

Mit ogr2osm habe ich mich bisher noch nicht beschäftigt.

Viele Grüße
Franz

5

Hallo Franz,

stimmt, ich habe noch keine Mail erhalten, wir können aber für alle einfacher nachvollziehbar einfach hier weiter kommunizieren.

Wie kannst Du denn ein Shape-File direkt in JOSM öffnen im wgs84 Format? Ich habe kein plugin gefunden.

Über meinen Weg (wenn dort der Fehler ist und dann beseitigt wäre) werden komplett die OSM Tags gesetzt und die Grenzwege sind genau bis zum nächsten gemeinsamen Knoten eines anderen Grenzwegs vorhanden, also die manuelle Nacharbeit in josm reduziert.

Viele Grüße

Dietmar

6

Hallo Dietmar,

Einfach über den Datei → Öffnen-Dialog

Ich war auch schon daran, mir ein kleines Programm zum automatischen Auftrennen der Grenzabschnitte zu schreiben. Aus zeitlichen Gründen bin ich aber nicht über die ersten Schritte hinaus gekommen. Deshalb käme es mir sehr gelegen, wenn die Abweichungen geklärt werden und ich auf Deine Daten zurückgreifen könnte.

Viele Grüße
Franz

7

Danke an Dietmar dafür, dass er sich um die Konvertierung und die Bereitstellung der Daten kümmert.

Unabhängig von den Schwierigkeiten bei der Konvertierung habe ich unter http://wiki.openstreetmap.org/wiki/Bayern/Gemeindegrenzen-OpenData-Initiative mal eine Wiki-Seite für den Datenimport aufgesetzt, mit einigen Erklärungen, Downloadadresse und vor allem einer Arbeitsliste.

Vorerst steht oben eine fette Warnung, dass die Daten wegen des Versatzproblems noch nicht verwendet werden sollen.

Solltet ihr Ergänzungen oder Änderungswünsche haben, bitte melden (oder einfach selbst eintragen).

8

Hallo Franz,

ich stehe auf dem Schlauch. Momentan bin ich nur auf meinem unix-Rechner aktiv und da im latest-josm kommt bei Datei → Öffnen bei Typ nichts mit Shape vor. Ein manuelle Eingabe bringt “Datei nicht vorhanden oder kein passender Importfilter”.
Wie heißt denn da der “Dateityp” im öffnen Dialog?
Arbeitest Du unter Windows?

Wenn da der gleiche GK->OSM Konverter genommen wird bei Datei → Import image, könnte da der Fehler liegen.
In dem Thread [1] wurde von bastik gesagt [2], das bei import image eine ungenauere Umrechung von GK nach WGS34 erfolgt.

Viele Grüße

Dietmar aka okilimu

[1] http://forum.openstreetmap.org/viewtopic.php?id=17659
[2] http://forum.openstreetmap.org/viewtopic.php?pid=261233#p261233

9

Hallo Dietmar,

Ja, ich arbeite uner Windows mit der Web-Start-Version von JOSM, Version ist 5576. Die Drop-Down-Liste bietet “Formdateien (*.shp)” zur Auswahl an.

Nach meinem Verständnis liegt die Shape-Datei ja schon im WGS84-Format vor und es braucht hier nichts mehr konvertiert werden. Wenn ich eine Original Shape-Datei öffnen will, erscheint eine Warnmeldung “JOSM konnte keine exakte Transformation zwischen DHDN_3_Degree_Gauss_Zone_4 und WGS84 gefunden werden. …” .

Ich vermute, entweder der Fehler liegt beim Konvertieren beim Export aus QGis. Das scheint mir auf den ersten Blick aber als unwahrscheinlich. Ich habe stichprobenartig den Standort von Punktobjekten mit GK-Koordindaten im Bayernviewer und mit auf gleiche Weise konvertierten WGS84-Koordinaten in JOSM auf Basis der neuen Bing-Luftbilder verglichen und dabei ist mir nichts derartiges aufgefallen.

Wie ist es bei ogr2osm, findet da auch eine Koordinatentransformation statt, wenn ja, wie wird sie gesteuert?

Zur Prüfung der korrekten Transformation an Hand bestimmter Punkte könnte man ggf. diese Seite benutzen: http://gdz.bkg.bund.de/web_koordtrans/start.html

Viele Grüße
Franz

10

Bestimmt nicht :wink:

Habe Dietmars osm an der mittelfränkischen/oberpfälzer Grenze verglichen (die Landkreise bzw. Regierungsbezirkgrenzen stammen aus einer besseren Quelle (siehe auch Wiki-Artikel von MetiorErgoSum);
Die Abweichung kann nur wenige Meter betragen.

“Schlimmer” dran sind die Grenzen derzeit im OSM in Bayern - welche nicht gleichzeitig Landkreis/Regierungsbezirksgrenzen sind -
z. B. im Landkreis Roth. Jene können durchaus 100 m (oder 200 m) daneben liegen, hat aber nix mit irgendwelchen Konvertierungsfehler zu tun.

@Dietmar
Das PlugIn für die .shp heisst “OpenData”: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData
Wie sinnig :slight_smile:

11

Hallo,

na dann ist ja gut, daß es dieser gerne gemachte Fehler nicht ist…

ja, wie andere hier schon geschrieben, ist die Tansformationsmethode ungenau…

Sven,

…der da zu NTv2 raten würde…

12

Auf jeden Fall eine Verbesserung gegenüber den bisherigen Grenzverläufen. Ein Fehler von wenigen Metern würde mir nichts ausmachen, wenn einheitlich und durchgehend auftreten würde, das merkt eh kaum einer, da es ja kaum feste Bezugspunkte in OSM für Grenzen gibt. Mich irritiert nur die unterschiedlichen Koordinaten aus der gleichen Datenquelle und ich würde zukünftig gerne die “richtigere” verwenden. Außerdem gehe den Dingen gern auf den Grund, um zu verstehen, warum etwas passiert.

Kennst Du eine Software, die Shape-Dateien mit Gauss-Krüger-Koordination mit NTv2-Transformation in WGS84 konvertiert? Die üblichen werden wohl mit der Helmert-Transformation arbeiten.

Grüße
Franz

13

Hallo,

ArcGis10…

privat hab ich die Version 10.1 Home-Use-Lizenz (kein kommerzieller Einsatz :frowning: )

diestlich 10.0 (ArcEditor-Lizenz). Da wäre das möglich. Ist eh nur eine Sache von Minuten…

Ich habe mittlerweile die osm-Datei von Niederfranken Unterfranken angeschaut (mit QGis und einem WMS-Dienst). Ich hab nur stichpunktartig geschaut. Die Linien lagen genau auf den Grenzlinien der TK. Das sah stimmig aus…

Ich weiß jetzt aber nicht genau, wie gut die Transformation mit QGis ist… müßte ich mal testen…

Sven

14

Ja, von diesem omninösen 8. Rbgz. von Bayern hab’ ich auch schon vernommen :wink:

15

Hallo,

Ach verdammt… ich bitte das Fränkische Volk zu tiefst um Verzeihung… ich meinte natürlich Unterfranken!

Asche auf mein Haupt…

entschuldigt sich Sven

16

Hallo Franz,

Ja, war Quatsch von mir.

Ich gebe dem Programm die Shape-Datei an und optional ein Perl-Skript, in dem die Umsetzung der Attribute gesteuert wird. Das Programm liest die .prj aus und gibt sich aus und rechnet dann.

Wenn ich Deinen Weg beschreite (ich hoffe, das ist er im folgenden), dann komme ich auch wieder auf meine Geometrien ohne jede Abweichung:
in QGIS 1.8.0-Lisboa unter Ubuntu 12.04 LTS

  • öffnen vector layer, iso-8859-1 encoding
  • Layer > Query “SCH” like “09771122”
  • Layer > Save as ESRI Shapefile, Encoding utf-8, CRS “Selected CRS”, “WGS 84” (Authority-ID EPSG:4326) OK

Sind das genau die Schritte, die Du machst?
Wenn ja: kannst Du diese nochmal wiederholen (und vielleicht die QGIS-Version angeben) und mir die o.g. Gemeinde Shape in WGS84 zusenden an strassenliste@diesei.de?

Stimmt, wenn ich hier eine einzelne GK4-Koordinate angeben erhalte ich in WGS84 eine Koordinate, die 3,6m nord-nord-westlich von meiner liegt.

Wenn ich die Original Bayern-Shape nehme und shp2osm.pl einsetze [1], kommt auch die Geometrie raus, die ich bereitgestellt hatte.

Viele Grüße

Dietmar

[1] http://wiki.openstreetmap.org/wiki/Shp2osm.pl

Edit: Schlüssel-ID korrigiert nach “09771122” (eine 7 fehlte)

17

Hallo Dietmar,

ich bin zwar in QGis nicht so firm, aber so würde ich es auch machen. Zu den Abweichungen zu NTv2 bei ArcGis kann ich nichts sagen, diesen Vergleich hab ich nicht gemacht. Ich transformiere recht wenig und wenn, dann Punktdaten von Pflanzen- und Tiernachweisen und da sind mit keine relevanten Unterschiede aufgefallen. Brandenburg hat ja bereits 1996 das zu WGS84 kompaktible ETRS89 (UTM-Zone33) eingeführt. Wenn es Unterschiede gibt dürften sie nicht allzu groß sein. Man könnte trotzdem Spaßeshalber einen Export-Vergleich machen, um zu sehen ob und wenja wie groß die Unterschiede sein könnten.

Falls angedacht: schicke bitte das Originalshape an sven(punkt)kasparz(at)naturschutzfonds.de. Wegen mir ganz Bayern oder in Teilen… Dann schaue ich mir das morgena mal an.

schlägt Sven vor.

18

Hallo,

nach etlichen Tests und unter Hilfe von zwei Mitschreibern hier im Thread, die auch ausgewertet haben hier mein aktueller Stand.

Die von Franz durchgeführte und von mir oben beschriebene Vorgehensweise (siehe Post von mir gestern 20:59:23), also nur in QGIS arbeitend und dort Transformation durchführend, dann in Josm Shape-File in WGS84 öffnen bringt bei mir unter Ubuntu 12.04 LTS in QGIS 1.8 mit älteren GDAL/OGR 1.7.3 einen Verzug von min 2,4m bis max 5,4m gegenüber meinem Windows Rechner mit QGIS und GDAL/OGR 1.9.1. [1]

Sven hat ganz Bayern auch konvertiert (ich habe keine Details, mit welcher Software). Da kommt was ähnliches raus wie bei o.g. GDAL/OGR 1.9.1 Einsatz (ok, die Grenzen sind dann 0,7 nach nordost-verschoben, aber das ist nach meiner Meinung vernachlässigbar). Mein Verzug gegen seine Auswertung beträgt min 2,7m bis max 4,8m.

Meine eingesetzen Programme ogr2ogr, ogr2osm, chp2osm.pl arbeiten mit diversen gdal-Bibliotheken und die sind bei mir alle 1.7.3.

Daher gehe ich davon aus, daß es einen relevanten Unterschied zw. Gdal 1.7.3 und 1.9.1 gibt. Mir ist aber der Aufwand zu hoch und vor allem habe ich zuwenig Ahnung, da tiefer einzusteigen, um das zu analysieren.

Ich werde heute oder spätestens morgen auf meinem Windows Rechner mit GDAL 1.9.1 die Regierungsbezirk-Einheiten erzeugen und dort die Transformation durchführen und danach auf meinem Ubuntu Rechner mir org2osm die pure Konverterierung Shape → OSM durchführen, da müsste dann das richtige hinten rauskommen.

Wenn ich das Ergebnis geprüft habe, werde ich die Zips im Downloadbereich aktualisieren und Bescheid geben.

Danke an Franz und Sven für die Unterstützung!

Sorry für den Fehler.

Viele Grüße Dietmar aka okilimu

[1] Die 1.9.1 GDAL/OGR gibt es dann in der neuen 12.10 Ubuntu Version, die ich noch nicht installiert habe.

19

Hallo,

Vvelleicht liegt es auch nur an falschen Transformationsparametern vom Bessel-Ellipsoid zum WGS84-Ellipsoid. Dazu wäre es interssant zu vergleichen, welches KBS nach dem Laden der originalen gmd_ex.shp in QGis eingestellt ist.

Bei mir ist es “Erzeugtes KBS …” mit folgenden Parametern:

+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7 +units=m +no_defs

Das sind dei gleichen Parameter wie in http://de.wikipedia.org/wiki/Helmert-Transformation beschrieben und in dem von mir oben verlinkten Transformationsdienst verwendet.

QGis verwendet meines Wissens PROJ.4 für die Koordinatentransformationen. Am Prinzip der Transformation hat sich ja nichts geändert und die Formeln sind auch noch einigermaßen überschaubar.

Ich nehme an, dass die von Sven gelieferte Version mit der NTv2-Transformation erstellt wurde. Die geringe Abweichung gegenüber der mit meinem QGis erstellten Daten spricht dafür, dass Sie im wesentlichen gleichwertig sind, die nach der NTv2-Methode sind prinzipbedingt aber die genaueren Werte.

Ich glaube, schön langsam nähern wir uns einer gemeinsamen Basis.

Viele Grüße
Franz

20

Hallo,

NTv2 ist eine Netzbasierte Transformationsmethode, d.h. für die Bereiche in Deutschland gibt es unterschiedliche Lagekorrekturwerte…
http://www.geobasis-bb.de/GeoPortal1/produkte/verm_bb/pdf/1_11_Kulawik_51-58.pdf
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007dokumentationV15.pdf

NTv2 schätze ich für unseren Zweck als das Genaueste ein.

Sven