Gemeindegrenzen Bayern - Wochennotiz Nr. 122

kartler175 · 2012-11-19 11:48:10

Liebe Mittmapper,

bitte mit der Verwendung der mit https://lists.openstreetmap.de/pipermai … 00642.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

streckenkundler · 2012-11-19 11:54:15

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

okilimu · 2012-11-19 12:51:12

kartler175 wrote:

Liebe Mittmapper,
bitte mit der Verwendung der mit https://lists.openstreetmap.de/pipermai … 00642.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

Den Kontakt hast Du erfolgreich hergestellt

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

kartler175 · 2012-11-19 13:34:00

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

okilimu · 2012-11-19 13:48:42

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

kartler175 · 2012-11-19 14:25:34

Hallo Dietmar,

okilimu wrote:

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

Einfach über den Datei -> Öffnen-Dialog

okilimu wrote:

Ü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.

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

MetiorErgoSum · 2012-11-19 14:36:18

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/Baye … 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).

okilimu · 2012-11-19 14:41:43

kartler175 wrote:

Hallo Dietmar,
okilimu wrote:
Wie kannst Du denn ein Shape-File direkt in JOSM öffnen im wgs84 Format? Ich habe kein plugin gefunden.
Einfach über den Datei -> Öffnen-Dialog
...
Viele Grüße
Franz

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/viewtopi … 33#p261233

kartler175 · 2012-11-19 15:28:27

Hallo Dietmar,

okilimu wrote:

Wie heißt denn da der "Dateityp" im öffnen Dialog?
Arbeitest Du unter Windows?

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.

okilimu wrote:

Wenn da der gleiche GK->OSM Konverter genommen wird bei Datei -> Import image, könnte da der Fehler liegen.

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

kellerma · 2012-11-19 16:45:22

streckenkundler wrote:

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.

Bestimmt nicht

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 … s/OpenData
Wie sinnig

Last edited by kellerma (2012-11-19 16:48:52)

streckenkundler · 2012-11-19 16:59:10

Hallo,

kellerma wrote:

Bestimmt nicht wink

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

kellerma wrote:

Die Abweichung kann nur wenige Meter betragen.

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

Sven,

...der da zu NTv2 raten würde...

kartler175 · 2012-11-19 18:06:01

streckenkundler wrote:

, wie andere hier schon geschrieben, ist die Tansformationsmethode ungenau...

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.

streckenkundler wrote:

...der da zu NTv2 raten würde...

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

streckenkundler · 2012-11-19 19:03:59

Hallo,

kartler175 wrote:

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.

ArcGis10...

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

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

Last edited by streckenkundler (2012-11-19 19:17:53)

kellerma · 2012-11-19 19:10:43

streckenkundler wrote:

Ich habe mittlerweile die osm-Datei von Niederfranken angeschaut

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

streckenkundler · 2012-11-19 19:16:53

Hallo,

kellerma wrote:

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

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

Asche auf mein Haupt...

entschuldigt sich Sven

okilimu · 2012-11-19 19:59:23

Hallo Franz,

kartler175 wrote:

Hallo Dietmar,
okilimu wrote:
Wenn da der gleiche GK->OSM Konverter genommen wird bei Datei -> Import image, könnte da der Fehler liegen.
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. ...." .

Ja, war Quatsch von mir.

kartler175 wrote:

Hallo Dietmar,
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?

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?

kartler175 wrote:

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

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)

Last edited by okilimu (2012-11-20 10:08:07)

streckenkundler · 2012-11-19 20:33:34

Hallo Dietmar,

okilimu wrote:

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 "0971122"
* Layer > Save as ESRI Shapefile, Encoding utf-8, CRS "Selected CRS", "WGS 84" (Authority-ID EPSG:4326) OK

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.

okilimu · 2012-11-20 14:43:45

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.

kartler175 · 2012-11-20 16:30:52

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

streckenkundler · 2012-11-20 16:48:39

Hallo,

NTv2 ist eine Netzbasierte Transformationsmethode, d.h. für die Bereiche in Deutschland gibt es unterschiedliche Lagekorrekturwerte...
http://www.geobasis-bb.de/GeoPortal1/pr … _51-58.pdf
http://crs.bkg.bund.de/crseu/crs/descrt … ionV15.pdf

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

Sven

okilimu · 2012-11-20 17:08:48

Hallo Franz,

kartler175 wrote:

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

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

kartler175 · 2012-11-20 17:51:24

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

streckenkundler · 2012-11-20 19:05:34

Hallo,

der

okilimu wrote:

Authoritäts-ID USER:100000 angegeben

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...

Sven

okilimu · 2012-11-20 20:15:29

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

ludwich · 2012-11-20 20:56:54

okilimu wrote:

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

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

Announcement

#1 2012-11-19 11:48:10

Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#2 2012-11-19 11:54:15

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#3 2012-11-19 12:51:12

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#4 2012-11-19 13:34:00

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#5 2012-11-19 13:48:42

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#6 2012-11-19 14:25:34

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#7 2012-11-19 14:36:18

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#8 2012-11-19 14:41:43

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#9 2012-11-19 15:28:27

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#10 2012-11-19 16:45:22

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#11 2012-11-19 16:59:10

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#12 2012-11-19 18:06:01

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#13 2012-11-19 19:03:59

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#14 2012-11-19 19:10:43

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#15 2012-11-19 19:16:53

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#16 2012-11-19 19:59:23

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#17 2012-11-19 20:33:34

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#18 2012-11-20 14:43:45

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#19 2012-11-20 16:30:52

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#20 2012-11-20 16:48:39

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#21 2012-11-20 17:08:48

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#22 2012-11-20 17:51:24

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#23 2012-11-20 19:05:34

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#24 2012-11-20 20:15:29

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

#25 2012-11-20 20:56:54

Re: Gemeindegrenzen Bayern - Wochennotiz Nr. 122

Board footer