Verschobene GPX Daten - wie korrigieren ?

Communities Deutschland (Germany)
1

Hallo

Das Gebiet was ich mappe ist bereits sehr detailliert erfasst, da alle Daten von der Kantonalen Verwaltung freigegeben wurden und vor paar Jahren in OSM importiert wurden ==> ich aktualisiere die Daten (neue Gebäude aufnehmen,…) da dies nicht mehr ausgeführt wird. Von diesem Verwaltungsportal (http://www.sogis1.so.ch/sogis/OnLineData/php/index.php) lassen sich extrem (!!) genaue und detaillierte DXF oder SHP Daten ziehen. Diese plane ich in JOSM zu öffnen und die fehlenden Gebäude,… nachzuzeichnen. Z.B. Gebäude lassen sich mit meinem GPS Logger nur sehr unpräzise (10 - 20 m Fehler) loggen. Die Gebäude welche ich nachtragen will sind allesamt sehr neu (paar Wochen bis 1.5 Jahre alt) und somit auf keiner Luftkarte (Google,…) vorhanden wo ich sie ebenfalls nachzeichnen könnte. Die amtlichen Vermessungsdaten sind die mit Abstand genausten und aktuellsten Daten.

  • Die shp Daten lassen sich mittels OpenData in JOSM jedoch nicht öffnen ==> Unable to detect CRS (den Fehler konnte ich bis jetzt noch nicht beheben. Da das Tool jedoch für jeden Layer ein shp File liefert, wird das ziemlich umständlich, denn es handelt sich um rund 50 Layers. Die Arbeit mit den DXF Daten erscheint mir einfacher ?)

  • Die dxf Daten konnte ich mittels dem Tool “dxf2gpx” von der OSM wiki in GPX oder OSM Daten umwandeln

  1. Leider sind diese GPX oder OSM Daten nach dem Öffnen in JOSM rund 5000 km zu weit südlich und etwas zu weit Westlich. Wie kann ich diese GPX Daten nachträglich korrigieren ohne jeden Datensatz einzeln im GPX File anzupassen (das GPX File ist 23 MB gross ==> von Hand unmöglich anzupassen). Kennt jemand ein Tool dafür ? Oder kann ich die GPX Daten irgendwie in JOSM “korrigieren” ?
2

Nahmd,

Meine Kristallkugel sagt mir, dass die Daten möglicherweise auch noch gedreht und zusätzlich verzerrt sein werden. Die 5000km Offset klingen nämlich nach Schweizer Landeskoordinaten: Nullpunkt irgendwo am Nordwestrand der Schweiz, während WGS84 den Nullpunkt am Äquator hat.

Ich empfehle, in irgendeinem der vorhergehenden Arbeitsschritte die Koordinaten umrechnen zu lassen “CH1903 → WGS84”. Per Hand drehen, schieben, zoomen wird nicht wirklich Spaß machen.

Gruß Wolf

3

Danke fürs Feedback.
Gedreht: Evtl. aber dann nur sehr leicht, die Ausreichtung der Daten (ist ein ganzes 6000 Seelen-Dorf) sieht eigentlich ganz gut aus.
Verzehrt: vielleicht, kann ich (noch) nicht beurteilen

Wie würde ich das tun ? Wie krieg ich die GXP Daten diesbezüglich “korrigiert” ? Ich kenne kein Tool und eine Google Recherche hat mich lediglich zu einem Toole (GXP Editor) geführt in welchem ich aber keine solche “Verschieben / Anpass” Funktion gefunden habe.

4

Hallo,

bei den Shape-Dateien sollte (im Normalfall) eine .prj Datei mit bei sein. Was steht denn da drin? In diesen PRJ-Dateien stehen die Referenzierungsinformationen des Shapes drin. Damit weis man, wo die Daten liegen… Wenn diese nicht vorhanden ist… helfen nur externe Quellen und “try and error”.

Sven

*)
http://support.esri.de/files/support/KoordinatensystemeNachbarnDeutschlands.pdf

5

In Bern stimmt alles, an der Westgrenze 1° nach rechts, am Bodensee 1.5° nach links, im Engadin 2° nach links gekippt (laut diesem PDF auf Seite 11)

Ich würde die Shapefiles konvertieren, das erzeugte GPX ist sicher unrettbar verkorkst… QGIS kann Schweizer Landeskoordinaten abspeichern (getestet), also sicher auch lesen (ungetestet) und dann als WGS84 abspeichern. Falls es ohne Oberfläche laufen soll, ogr2ogr kann das sicher auch (sagt man).

Grüße, Max

Hast mal eine Beispiel-Shapedatei? Dann probier ich das gerne mal aus…

6

Autsch … sicher nur verschrieben, da wir von Google nicht abzeichnen.

7

nein, leider nur die folgenden Files im Export enthalten:

  • .shp
  • .dbf
  • .qix
  • .shx

Externe Quellen: Gibt es da welche ? Kann ich mir das PRJ “selber basteln” ? Da die allermeisten Orte bereits vorliegen könnte ich das wohl schrittweise annähern und ein Versatz von 1 - 2 m wäre wohl kein Problem da rund herum so viele Objekte vorhanden sind an denen ich mich orientieren könnte. Es sind ja nur ein paar wenige fehlende Objekte zum nachtragen.
Habe auf der Verwaltung nachgefragt ob diese Info erhältlich ist.

Ich kann das File (als zip, da es sehr viele einzelne Dateien enthält) gerne zur Verfügung stellen (Man kann sich auf SOGIS gratis registrieren und die Files herunterladen, weshalb ich davon ausgehe, dass dies ok ist). Der DL Link lautet: guldi.dyndns.tv/Derendingen_shp.zip

8

in der ZIP-Feile nur:

-dbf: =Sachdaten
-shp: =Geodaten
-shx: =index-Datei…

Mist… das absolut nötige Minimum…

Sven

9

Da fehlt die prj-Datei, riecht aber nach Schweizer Landeskoordinaten…
Probiers mal damit: http://geo.dianacht.de/tests/Derendingen_shp_wgs84.zip
Die ist in WGS84, umgewandelt mit ogr2ogr und dem NTv2-Datensatz von hier.

10

Muss leider gleich los: aber ganz kurz anschauen konnt ich es noch ==> sieht PERFEKT aus, deckt sich 100% mit bestehenden OSM Daten. Vielen vielen Dank !
Komme vielleich nochmals auf dich zu wenn ich es mit dem selber korrigieren (es gibt ja noch Nachbarsgemeinden) nicht hinbekomme, kenne das Tool ogr2ogr (noch) nicht.
Allen einen schönen, erfolgreichen Tag

11

Fein. Dann fürs Protokoll die Parameter für die Umwandlung von CH1903 nach WGS…

In der mitgelieferten epsg-Datei von GDAL stand bei mir

<21781> +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +units=m +no_defs

Das sollte auch gehen, ist auch das was man bei spatialreference.org für “EPSG:21781 ( CH1903 / LV03)” findet, hat aber so um einen Meter Abweichung zu den Beispielen in der Wikipedia.
Also hab ichs mal testweise mit der Datei “chenyx06etrs.gsb” von swisstopo probiert:

<21781>  +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1  +x_0=600000  +y_0=200000 +ellps=bessel +nadgrids=chenyx06etrs.gsb +units=m +no_defs <>

und kam auf schönere Ergebnisse.

Umwandeln geht dann einfach mit

ogr2ogr Zielordner Quelldatei.shp -s_srs EPSG:21781 -t_srs EPSG:4326

als Ergebnis hat man dann eine umgewandelte “Quelldatei.shp” im Zielordner. Für viele Dateien nimmt man da vielleicht besser ein kleines script

for i in *.shp ; do ogr2ogr zielordner $i -s_srs EPSG:21781 -t_srs EPSG:4326 ; done
12

Gibt es dazu irgenwo etwas im Wiki, sodass man dies dort mit ergänzen kann?

13

Ich habe mir ogr2ogr via FWTools247 unter win7 installiert. In der FWTools Shell konnte ich ogr2ogr mit obigem cmd anwerfen und ich bekam prompt auch ein konvertiertes shp zurück (das merkwürdigerweise aber gut 2.5 mal so gross war wie das Ursprungs Shp File. Das konvertierte File von dir Maxbe war ja nahezu identisch in der Grösse). In JOSM geöffnet und als GPX Ebene konvertiert (so kann ich es einfach abzeichnen*) liegen die Daten exakt (naja, teilweise um max 0.005m daneben :slight_smile: wie diejenigen von dir ==> sieht somit gut aus.
Was ich nicht verstanden habe ist:

  1. Weiter oben erwähnst du einen NTv2-Datensatz. Benötige ich diesen, wenn ja wie muss ich diesen in ogr2ogr “einbinden” ? Das sieht mir nach einem “KorrekturGitter” für weiter oben erwähnte 1.x° Verzerrung aus.

  2. Du schreibst etwas von einer Datei “chenyx06etrs.gsb” von swisstopo, was hat es damit auf sich ? Benötige ich diese, wenn ja wie muss ich diesen in ogr2ogr “einbinden” ?

Bin leicht verwirrt da bereits mit obigem ogr2ogr Aufruf die konvertierten Daten sehr gut aussehen.

Übrigens: obiger code angeworfen ohne Quelldatei jedoch mit einem Quellverzeichniss, konvertiert bei mir sämtliche shp Dateien in diesem Verzeichniss. Die Schlaufe mit for i… scheint somit unnötig.

Ich habe unterdessen auch Feedback von der Kantonalen Verwaltung erhalten welche den Datenimport vor paar Jahren aus dieser SOGIS Datenbank in OSM durchgeführt hat. Ja es handelt sich um LV03 (Schweizer Koordinaten) Daten in der SOGIS Datenbank. Sie haben mir ogr2ogr zur Konvertierung empfohlen aber trotzdem noch ein prj File gesendet. Ich habe dieses umbenannt so dass es gleich lautet wie die shp Datei und konnte damit in JOSM / OpenDate das ursprüngliche shp File öffnen. JOSM reklamierte aber etwas von einer unzureichenden Genauigkeit und tatsächlich waren die Daten damit rund 100m verschoben. Egal, es geht ja jetzt mit dem Konvertieren.

Falls gewünscht kann ich obiges Vorgehen in ein wiki tippen. Wo ?

  • Die SOGIS Daten erlauben in dem Fall das Abzeichnen, auch wenn JOSM einem darauf hinweist, dass “wir” nicht abzeichnen :wink: Genauere Daten wie diese Kantonalen Vermessungsdaten gibts aber wohl nicht.
14

Diese chenyx06etrs.gsb ist der Datensatz für NTv2.

Ich bin mir nicht mal sicher, dass ich alles verstanden hab, aber ich bin mir sicher, dass ich das nicht erklären kann, ohne dass die anderen lachen :wink: Deshalb nur ganz kurz:

Beim Umwandeln von älteren Netzen mit anderen Ellipsoiden (Bessel z.B.) gibt es Abweichungen, wenn man einfach nur die Ellipsoiden schiebt und dreht (die Daten hinter “+towgs84”). Die sind vielleicht in der kleinen Schweiz nicht gross (darum wäre ich auch mit den paar cm zufrieden und würde mich um die Datei nicht kümmern), aber in Deutschland recht deutlich.

Hier weisen Leute, die sich besser auskennen, oft darauf hin, dass man NTv2 vorziehen soll. Da sind Messpunkte hinterlegt mit den Abweichungen und dazwischen wird interpoliert. Diese Daten zur Interpolation stecken in der gsb-Datei.
Das deutsche Gegenstück zu der “chenyx06etrs.gsb” heisst “BETA2007” (braucht man wenn man Gauß-Krüger-Daten vom Amt bekommt), Forensuche danach bringt ein paar Diskussionen zum Thema. Vielleicht erbarmt sich auch ein Kundiger und erklärt das besser.

Der Kippeffekt mit 1° hat nichts damit zu tun. Der ergibt sich einfach daraus, dass man ein rechtwinkliges Koordinatensystem auf die runde Erde klebt. Das Schweizer Netz ist in Bern nach Norden ausgerichtet. Wenn man sich dort in Richtung Osten dreht und immer gerade aus geht, kommt man immer weiter ein kleines Stück nach Süden (wem hier die Vorstellungskraft versagt, soll sich das an einem Punkt 100m südlich des Nordpols vorstellen und sich von oben betrachten). Der Effekt ist um so grösser, je weiter man von Bern weg kommt, deshalb am Bodensee 1.5° und im Engadin 2°. Um all das musst Du dich aber nicht mehr kümmern. “+proj=somerc” drückt die Ausrichtung des Koordinatensystems schon aus (“swiss oblique mercator”, eine Mercatorprojektion auf einen Zylinder, der schief ist gegenüber der Erdachse, so dass er sich an einem bestimmten Punkt an die Erdoberfläche anschmiegt), dieser Punkt in Bern ist durch lat_0 und lon_0 festgelegt.

Grüße, Max

15

Hallo Zusammen,

Im Prinzip ist das Richtig. NTv2 ist eine Netzbasierte Transformationsmethode. Man kann es sich folgendermaßen merken: über das betreffende Feld wird ein Netz gelegt. Jeder Netzknoten hat dann seinen eigenen Korrekturwert. Dieses stehr in der *.gsb-Datei drin…

Ich glaube, das ist einfach genug…
:slight_smile:

Sven

16

ok, aber nochmals zu meiner Frage zurück: mit obigem ogr2ogr Aufruf habe ich diese “chenyx06etrs.gsb” Korrekturdatei nicht mit einbezogen (die Datei ist in der FWTools Installation nicht enthalten ergo gehe ich davon). ==> Das heisst dann wohl die shp Datei wurde bei meinem Aufruf ohne diese Korrekturdaten umgewandelt was zu diesen sehr leichten (paar cm) Abweichungen führte, hab ich das korrekt verstanden ?
Wie würde ich denn diese “chenyx06etrs.gsb” Korrekturdaten einbinden, ich kann im “ogr2ogr” Aufruf kein Parameter erkennen womit ich eine gsb Datei anziehen würde ?
Ich habe verstanden dass man in der Schweizer OSM-Welt mit diesen minimalen Abweichungen leben kann, nur der Vollständigkeitshalber diese Frage :slight_smile:

17

Ja.

Der Parameter für die gsb-Datei steckt in der Konfigurationsdatei für proj.4 (das ist das Ding, das für ogr2ogr die Projektion macht). Bei mir heisst diese Datei “epsg”, aber ich weiss nicht wie die auf Win7 heissen muss. Das muss ein Windows-Nutzer erzählen. Vielleicht kann ichs in der Arbeit mal probieren…

Falls Du die Konfigurationsdateien nicht findest, kannst Du auch einfach in der Kommandozeile die Parameter angeben:

ogr2ogr Zielordner Quelldatei.shp  
   -s_srs "+proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +nadgrids=chenyx06etrs.gsb  +units=m +wktext" 
   -t_srs "+proj=longlat +ellps=WGS84 +datum=WGS84"

(alles in einer Zeile)

Dass ogr2ogr die Datei verwendet, erkennst Du an den paar cm Abweichungen gegenüber den anderen Daten.
Falls er die Datei nicht findet oder nicht verwendet, solltest Du nach dem Kommando da oben ein paar zig Meter Abweichung sehen. Weil dann wird weder nadgrids verwendet noch towgs und es geht richtig schief.

Ich glaube chenyx06etrs.gsb muss dabei im aktuellen Verzeichnis liegen oder mit Pfad eingebunden werden.

18

Sorry, dass ich das wieder aufwärme, aber ich wills abschliessen und ich komme ja so selten an einen Rechner mit dem richtigen Betriebssystem. Bei einem Windows XP mit installiertem FWTools 247 sieht das jetzt bei mir so aus:

Im Verzeichnis “C:\Programme\FWTools2.4.7\proj_lib” liegt eine Datei “epsg”, die eine Zeile für jede EPSG-Nummer enthält. Da steht z.B. für 21781

# CH1903 / LV03
<21781> +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +units=m +no_defs  <>

Ich hab dann diese chenyx06etrs.gsb runtergeladen, in das o.g. Verzeichnis kopiert und den Eintrag abgeändert in

# CH1903 / LV03
#<21781> +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +units=m +no_defs  <>
<21781> +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel  +nadgrids=chenyx06etrs.gsb +units=m +no_defs

(die originale Zeile hab ich mal auskommentiert behalten, man weiss ja nie…)

Zum Testen, ob das in den FWTools auch verwendet wird, nehme ich “cs2cs”, das einzelne Koordinaten umwandeln kann, z.B. (8E, 47N)

C:\Programme\FWTools2.4.7>echo 8 47 | cs2cs +init="EPSG:4326" +to +init="EPSG:21781"

Das Ergebnis daraus mit dem Umrechner von swisstopo verglichen:

(8,47) ohne .gsb   642695.42       205590.52
       mit .gsb    642694.86       205590.53
       swisstopo   642694.859      205590.518

(9,46) ohne .gsb   720956.89       95474.53
       mit .gsb    720956.63       95475.73
       swisstopo   720956.625      95475.730

Man kommt also bei diesen beiden Testfällen mit der gsb-Datei auf nen Zentimeter ans “amtliche” Ergebnis ran, ohne diese Datei auf einen halben Meter. Liegt vermutlich daran, dass auch swisstopo mit chenyx06etrs.gsb rechnet, vielleicht nur anders rundet…

viele Grüße, Max