Unterschiede in epsg:31468 und epsg:4326 Transformationen JOSM/QGIS

Hei,

Also: EPSG 31468 ist Gauss-Krüger 4. Meridianstreifen und EPSG 4326 ist WGS84

Bei 31468 liegt das Bessel-Ellipsoid zu Grunde mit Gauss-Krüger-Projektion
Bei 4326 liegt das WGS84-Ellipsoid zu Grunde ohne Projektion.

Beide Ellipsoide unterscheiden sich in ihren Parametern, so daß Daten am besten physisch umgerechnet werden müssen. Macht man das nicht, kommt es zu dem von dir beschriebenen Lagebezugsfehler. Ich glaube JOSM kann nicht unrechnen und nicht onTheFly Gauss-Krüger-Daten korrekt umprojizieren. Solcher Lageversatz kann bis zu 70 bis 120m betragen, je nach Ort.

Solche Transformation kann und würde ich stets vorher mit einem "großen" Gis-Programm machen: ArcGis oder QGis

Bei solchen Umrechnungen gibt es verschiedene Transformationsmethoden. Ich würde NTv2 BETA2007 empfehlen. Das ist eine Netzbasierte Transformationsmethode und das genauste, was es gibt.

Sven

streckenkundler wrote:

Bei solchen Umrechnungen gibt es verschiedene Transformationsmethoden. Ich würde NTv2 BETA2007 empfehlen. Das ist eine Netzbasierte Transformationsmethode und das genauste, was es gibt.
Sven

Ok - wie bringe ich QGIS dazu diese Trafo zu verwenden? Bzw. ich importiere die shapes in QGIS - wie geht's dann weiter? Wenn ich das recht verstehe, dann reicht ja ein einfacher Export nach 4326 nicht aus... Allerdings ist ein derartig über QGIS konvertiertes und dann in JOSM importiertes shape file tatsächlich um 2 Meter gegenüber dem initialen direkt import der 31468 shape verschoben.

D.h. wir werden wohl alle Imports entsprechend anpassen müssen :-/

was soll das EPSG:4326, der allgemeine standard von josm ist doch EPSG:3857?

Chenshi wrote:

was soll das EPSG:4326, der allgemeine standard von josm ist doch EPSG:3857?

4326 ist das übliche System, in dem wir Daten eintragen (Längengrad und Breitengrad auf einer leicht elliptischen Erde). 3857 ist das System in dem viele unserer Karten gerendert werden (Mercatorprojektion auf einer Kugel).

Edit zur Klarstellung: Die Darstellung in JOSM ist fast immer in EPSG:3857. Weil da sind Kreisverkehre auch kreisförmig statt flachgedrückt und die Hintergrundbilder müssen nicht verzerrt werden. In die Datenbank wird aber EPSG:4326 geschrieben.

Chenshi wrote:

was soll das EPSG:4326, der allgemeine standard von josm ist doch EPSG:3857?

EPSG 4326
EPSG 3857

EPSG 4326 ist eigentlich die Basis. EPSG 3857 bautdarauf auf (Siehe Unterschied im Wert Unit)

Sven

Arminus wrote:

Ok - wie bringe ich QGIS dazu diese Trafo zu verwenden?

Gute Frage... Ich staune ohnehin daß es noch irgendwo Daten in Gauss-Krüger gibt... 😠 Ich stoße bei meiner GIS-Arbeit (dienstlich) nur an 2 Stellen auf Gauss-Krüger: entweder alte Artdaten oder Daten (hier in Brandenburg) der LMBV... Bei allen anderen Daten habe ich seit mindesten 10-12 Jahren kein Gauss-Krüger mehr gesehen...

Bei QGis müsste ich auch erst schauen,. wie der Weg beim Export wäre...

Mein Angebot: schicke mir die Daten, ich konvertiere die mit ArcGis (hab es privat als HomeUse-Variante).

Sven

Andere Formulierung:
EPSG 4326 (WGS 84) ist ein sphärisches Koordinatensystem, EPSG 3857 (Mercator) ist eine Kartenprojektion davon auf eine ebene Fläche. Nur dadurch wird ein Ei zum Kreis.
BaWü hat übrigens noch gar nicht so lange her von GK umgestellt. In QGis geht die Transformation auf jeden Fall, habe das damals in der Version BETA2007 gemacht.

Arminus wrote:

Aktuell habe ich eine Implementierung die sich auf einen Intersection over Union Wert abstützt und zum Anderen versucht solche ~ 2 meter offsets - die ich in python/fiona/shapely ebenfalls bekomme - zu erkennen und weg zu filtern.

Hallo Arminus,

wäre es möglich deinen Source Code irgendwo zugänglich zu machen?

Es spricht nichts gegen eine selbstgebaute Python-Lösung statt QGIS: Die proj-Bibliothek, die die Basis für fiona, shapely, etc. bildet, bringt die hochgenaue NTv2-Transformation BeTA2007 für Deutschland schon mit unter /usr/share/proj/BETA2007.gsb (https://github.com/OSGeo/PROJ/blob/mast … TA2007.gsb).

Vermutlich wird sie einfach nicht – oder nicht richtig – benutzt von deinem Skript.

Viele Grüße,
Günter

streckenkundler wrote:

Gute Frage... Ich staune ohnehin daß es noch irgendwo Daten in Gauss-Krüger gibt... 😠

So kommen die Daten zunächst mal vom Deutschen Alpenverein (wie an andere Stelle erwähnt, das ok für die Verwendung haben wir)

streckenkundler wrote:

Bei QGis müsste ich auch erst schauen,. wie der Weg beim Export wäre...

Wie gesagt, in QGIS "einfach in EPSG 4326" exportieren scheint nach meinem Empfinden den Offset zu beheben - ob's da im Zentimeter-Bereich noch Ungenauigkeiten gibt kann ich aber nicht beurteilen. Ich bin halt Informatiker und kein GIS Ingenieur ;-)

streckenkundler wrote:

Mein Angebot: schicke mir die Daten, ich konvertiere die mit ArcGis (hab es privat als HomeUse-Variante).

Das ist nett, können wir auch einmal versuchen, aber es wird regelmäßige Updates für die Shapes vom DAV geben, d.h. ich möchte eigentlich schon verstehen was an der Stelle wo und warum passiert ;-) Zumal ich ja auch einen brauchbaren Diff implementieren möchte und aktuell mit pyproj den gleichen Effekt habe :-(

Außerdem muss ich mir jetzt noch überlegen wie ich am effektivsten die offensichtlich 2 Meter daneben gemappten Gebiete gefixt bekomme. Also entweder manuell auf die neu konvertierten Shapes hin ziehen, oder löschen und neu kopieren... So wie ich das sehe hat JOSM keine move line / snap funktion.

Arminus wrote:

So wie ich das sehe hat JOSM keine move line / snap funktion.

Das utils2 Plugin hat eine replace geometry Funktion: https://wiki.openstreetmap.org/wiki/JOS … ilsplugin2

Arminus wrote:

So kommen die Daten zunächst mal vom Deutschen Alpenverein.

Toll. Ich dachte immer, die würden mauern und "Ihre Daten" nicht rausgeben. Und auf keinen Fall an OSM.

Oder sind die Daten nur von einem Untervereinchen? 😉

Gruss
walter, der eigentlich von den Alpen keine Ahnung hat.

Arminus wrote:

Das ist nett, können wir auch einmal versuchen, aber es wird regelmäßige Updates für die Shapes vom DAV geben, d.h. ich möchte eigentlich schon verstehen was an der Stelle wo und warum passiert ;-)

Dann kann ich nur dem DAV den gut gemeinten Rat geben... auf ETRS89 umzusteigen... Da hat man einmalig diese Konvertierung der Datenhaltung, ist Datentechnisch auf dem neusten Stand und umgeht diese Gauss-Krüger-Transformatiererei...

Meine Meinung...

Sven

wambacher wrote:

Oder sind die Daten nur von einem Untervereinchen? 😉

Nein, die Daten kommen vom Ressort Naturschutz und Kartografie beim DAV.

SammysHP wrote:

Arminus wrote:

So wie ich das sehe hat JOSM keine move line / snap funktion.

Das utils2 Plugin hat eine replace geometry Funktion: https://wiki.openstreetmap.org/wiki/JOS … ilsplugin2

Vielleicht hilft Dir auch das Conflation-Plugin, was "replace geometry" verwenden kann.

Arminus wrote:

Das ist nett, können wir auch einmal versuchen, aber es wird regelmäßige Updates für die Shapes vom DAV geben, d.h. ich möchte eigentlich schon verstehen was an der Stelle wo und warum passiert ;-) Zumal ich ja auch einen brauchbaren Diff implementieren möchte und aktuell mit pyproj den gleichen Effekt habe :-(

Für automatische Abläufe würde ich mal einen Blick auf ogr2ogr werfen... Könnte des nachts im Hintergrund ganz ohne Maus in der Hand laufen und kann genauso gut konvertieren wie qgis (weil ja eh fast alle die proj.4-Bibliothek nehmen, nur halt unterschiedlich Parameter da reinfüttern)

ogr2ogr ist in GDAL enthalten

Danke, ogr2ogr verwende ich bereits an anderer Stelle. Ich hatte gedacht, dass Transformation mit anderen Tools (JOSM, pyproj) sich genauso verhalten, aber das war offensichtlich naiv 😉

Kurzer Update zu diesem Thema (und falls das irgendwer irgendwann mal an anderer Stelle braucht):

streckenkundler wrote:

Bei solchen Umrechnungen gibt es verschiedene Transformationsmethoden. Ich würde NTv2 BETA2007 empfehlen. Das ist eine Netzbasierte Transformationsmethode und das genauste, was es gibt.
Sven

QGIS wendet diese Methode offenbar auch an und ich habe inzwischen gelernt, dass man den Python pyproj.Transformer auch mit einem proj pipeline String initialisieren kann.

Beim Laden eines EPSG:31468 shapes in ein EPSG:4326 Projekt in QGIS wird dort als erstes dieser pipeline string angezeigt:

+proj=pipeline
+step␣+inv␣+proj=tmerc␣+lat_0=0␣+lon_0=12␣+k=1␣+x_0=4500000␣+y_0=0␣+ellps=bessel
+step␣+proj=hgridshift␣+grids=BETA2007.gsb
+step␣+proj=unitconvert␣+xy_in=rad␣+xy_out=deg

Den kann man 1:1 in pyproj.Transformer.from_pipeline() übernehmen und dann sollte das (ggf. erst dann in JOSM zu importierende) EPSG:4326 Ergebnis dort auch passen.