Aktionen

GEOTRANSFORMER: Unterschied zwischen den Versionen

Aus BAWiki

imported>Seiss Guntram
K (Geographisch Amersfoort ergänzt)
imported>Seiss Guntram
K (Hinweis auf die zu erwartende Performanz)
Zeile 21: Zeile 21:


|kurzbeschreibung=Dieses Programm transformiert für verschiedenen Dateiformate der BAW die Koordinaten zwischen verschiedenen Koordinaten-Systemen und geodätischen Datumstransformationen.
|kurzbeschreibung=Dieses Programm transformiert für verschiedenen Dateiformate der BAW die Koordinaten zwischen verschiedenen Koordinaten-Systemen und geodätischen Datumstransformationen.
Derzeit implementierte Koordinaten-Systeme sind:
Derzeit implementierte Koordinaten-Systeme sind:


Zeile 41: Zeile 42:
* Bundesamt für Kartographie und Geodäsie, Breiten zwischen 50,3 Grad N und 52,3 Grad N
* Bundesamt für Kartographie und Geodäsie, Breiten zwischen 50,3 Grad N und 52,3 Grad N
* Bundesamt für Kartographie und Geodäsie, Breiten <50,3 Grad N
* Bundesamt für Kartographie und Geodäsie, Breiten <50,3 Grad N
* Das holländische Bessel-Ellipsoid (Amersfoort Datum)


Zudem besteht innerhalb Deutschlands die Möglichkeit, die Datumstransformation von DHDN90 nach ETRS89 und umgekehrt über das gitterbasierte NTv2-Verfahren nach GNTRANS-WSV oder BETA2007 vorzunehmen.
Zudem besteht innerhalb Deutschlands die Möglichkeit, die Datumstransformation von DHDN90 nach ETRS89 und umgekehrt über das gitterbasierte NTv2-Verfahren nach GNTRANS-WSV oder BETA2007 vorzunehmen.
Das Programm kann im Batchbetrieb eingesetzt werden. Hinsichtlich der Datenmenge gibt es keine Beschränkungen, da die Dateien sequentiell bearbeitet werden. Für 25 Mio. Koordinatenpaare (Gauß-Krüger/DHDN <-> UTM/ETRS89) benötigt das Programm auf einer handelsüblichen INTEL-CPU derzeit 280,68 Minuten inklusive Ein- und Ausgabe.


|eingabedateien=
|eingabedateien=

Version vom 23. Februar 2016, 12:14 Uhr

Basisinformationen

Programm-Name

GEOTRANSFORMER

Version

Januar 2016

Beschreibung

Januar 2016

Stichworte

Koordinaten-Transformation
Koordinaten-System
Gauß-Krüger
Universale Transverse Mercator Projektion
Universale Polar Stereografisch Projektion
Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)
World Geodetic System 1984 (WGS84)
European Datum 1950 (ED50)
Potsdam Datum (Bessel 1841)
Krassowski-Ellipsoid
NTv2-Verfahren
BETA2007
GNTRANS-WSV
Rijksdriehoeksmeting (RD, niederl. Koordinatensystem)
BAW-Dateiformate

Kurzbeschreibung

Dieses Programm transformiert für verschiedenen Dateiformate der BAW die Koordinaten zwischen verschiedenen Koordinaten-Systemen und geodätischen Datumstransformationen.

Derzeit implementierte Koordinaten-Systeme sind:

  • Gauß-Krüger (Streifen 2 bis 5)
  • Sphärische Koordinaten (geografische Länge und Breite)
  • Universal Transverse Mercator (UTM)
  • Rijksdatum (Niederlande)
  • lokale metrische Zentralprojektion

Derzeit implementierte geodätische Datumstransformationen (7-Parameter-Transformationen) sind

  • Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)
  • World Geodetic System 1984 (WGS84)
  • European Datum 1950 (ED50)
  • Bundesamt für Kartographie und Geodäsie, Standard-Parameter
  • Bundesamt für Kartographie und Geodäsie, Breiten >52,3 Grad N
  • BAW C. Maushake,
  • Krassovsky Standard (Wikipedia)
  • Krassovsky (WSA Stralsund)
  • Bundesamt für Kartographie und Geodäsie, Breiten zwischen 50,3 Grad N und 52,3 Grad N
  • Bundesamt für Kartographie und Geodäsie, Breiten <50,3 Grad N
  • Das holländische Bessel-Ellipsoid (Amersfoort Datum)

Zudem besteht innerhalb Deutschlands die Möglichkeit, die Datumstransformation von DHDN90 nach ETRS89 und umgekehrt über das gitterbasierte NTv2-Verfahren nach GNTRANS-WSV oder BETA2007 vorzunehmen.

Das Programm kann im Batchbetrieb eingesetzt werden. Hinsichtlich der Datenmenge gibt es keine Beschränkungen, da die Dateien sequentiell bearbeitet werden. Für 25 Mio. Koordinatenpaare (Gauß-Krüger/DHDN <-> UTM/ETRS89) benötigt das Programm auf einer handelsüblichen INTEL-CPU derzeit 280,68 Minuten inklusive Ein- und Ausgabe.

Eingabe-Dateien

  1. Gitternetzdatei (Dateityp TICAD,gitter05.dat/bin) oder
  2. digitalisierte Linien (Dateityp digi.gkk) oder
  3. digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp insel.dat) oder
  4. Polygondateien (Dateityp poly.dat) oder
  5. Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp nodes.save) oder
  6. (Dateityp frames.dat, der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
  7. Beschreibung der Randgitterzellen (Dateityp rgz.dat) oder
  8. ASCII-Format für Punktdaten, Peildatendatei (Dateityp geom.dat) oder
  9. Zeitreihendateien an Einzelstationen (Dateityp boewrt.dat) oder
  10. Geopositionsdatei (Dateityp geopos.dat) oder
  11. UNTRIM-VC-Gitternetzdatei (Dateityp untrim_grid.dat, Variante Vincento Casulli) oder
  12. DELFT3D-Gitternetzdatei (Dateityp delft3d.grd) oder
  13. UNTRIM-BAW-Gitternetzdatei (Dateityp untrim_grid.dat, Variante BAW) oder
  14. Systemdatei für Einzelpositionen (Dateityp location_grid.dat) oder
  15. IPDS-Datei zur Initialisierung von Anfangsfeldern (Dateityp ipds.dat) oder
  16. World-Datei zur Beschreibung der Georeferenzierung eines Images (typische Datei-Endungen sind .pngw, .jpgw, .gifw) oder
  17. Profilgitter (Dateityp profilo5.bin.

Ausgabe-Dateien

  1. Gitternetzdatei (Dateityp TICAD,gitter05.dat/bin) oder
  2. digitalisierte Linien (Dateityp digi.gkk) oder
  3. digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp insel.dat) oder
  4. Polygondateien (Dateityp poly.dat) oder
  5. Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp nodes.save) oder
  6. (Dateityp frames.dat, der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
  7. Beschreibung der Randgitterzellen (Dateityp rgz.dat) oder
  8. ASCII-Format für Punktdaten, Peildatendatei (Dateityp geom.dat) oder
  9. Zeitreihendateien an Einzelstationen (Dateityp boewrt.dat) oder
  10. Geopositionsdatei (Dateityp geopos.dat) oder
  11. UNTRIM-VC-Gitternetzdatei (Dateityp untrim_grid.dat, Variante Vincento Casulli) oder
  12. DELFT3D-Gitternetzdatei (Dateityp delft3d.grd) oder
  13. UNTRIM-BAW-Gitternetzdatei (Dateityp untrim_grid.dat, Variante BAW) oder
  14. Systemdatei für Einzelpositionen (Dateityp location_grid.dat) oder
  15. IPDS-Datei zur Initialisierung von Anfangsfeldern (Dateityp ipds.dat) oder
  16. World-Datei zur Beschreibung der Georeferenzierung eines Images (typische Datei-Endungen sind .pngw, .jpgw, .gifw) oder
  17. Profilgitter (Dateityp profilo5.bin.

Methode

  • Ein- und Ausgabe-Datei sind zeitgleich geöffnet. Jeder gelesene Koordinaten-Punkt wird sofort transformiert und in die Ausgabe-Liste geschrieben. Dadurch kann die Anzahl der zu transformierenden Koordinaten in der Eingangs-Liste beliebig groß sein.
  • Das Programm formatiert die Ausgabedateien entsprechend der geforderten Genauigkeiten in der Nachkommastelle unterschiedlich, je nach dem, ob geographische Koordinaten oder Kartenkoordinaten zu schreiben sind. Beim Dateityp 08 (ASCII-Format für Punktdaten) kann die Ausgabe in Kartenprojektionen über die Umgebungsvariable GEOMFMT frei gesteuert werden, um z.B. die Dateigröße zu reduzieren.
  • Das Programm transformiert die in der Ausgangsprojektion vorliegenden Koordinatenpaare zunächst in sphärische Koordinaten (WGS84) und dann weiter in das geodätische Zieldatum und die Zielprojektion. Bei der Datumstransformation kann im Falle "Eingangs- und/oder Ausgangsdaten in DHDN oder STN" anstelle einer 7-Parameter-Transformation das NTv2-Verfahren unter Nutzung eines Transformationsgitters (*.gsb) eingesetzt werden (Defaulteinstellung!). Es sollten die aktuellen NTv2-Gitterdateien des GNTRANS-WSV-Systems genutzt werden. ATKIS-konforme Transformationen erhält man unter Verwendung der Gitterdatei BETA2007.gsb.
  • In der Eingabe sind beim Dateiformat 08 (geom.dat) als Trenner der Spalten auch die Zeichen Semikolon, Komma uns Doppelpunkt erlaubt.
  • Bei den Dateiformaten 09 (boewrt.dat), 10 (geopos.dat), 13 (untrim_grid.dat, Variante BAW) und 14 (location_grid.dat) erfolgt ggf. erst eine Transformation in das Input-Koordinatensystem, falls diese Dateien bereits eine gültige Information über ihr Koordinatenreferenzsystem enthalten. Bei den ASCII-Formaten 01 (gitter05.dat), 02 (digi.gkk) und 08 (geom.dat) kann das (bekannte) Koordinatenreferenzsystem der Ausgangsdaten über die Kommentarzeile "C CRS=#####" am Anfang der Datei spezifiziert werden. "#####" ist hier ein von libgeodesy unterstützter EPSG-Code (s.u.). In diesem Fall wird ebenfalls zunächst eine Transformation in das Input-Koordinatenreferenzsystem durchgeführt. Das Input-Koordinatenreferenzsystem muss dabei einen gültigen EPSG-Code (s.u.) besitzen.
  • In den Dateien 10 (geopos.dat), 13 (untrim_grid.dat, Variante BAW) und 14 (location_grid.dat) wird, falls die Umgebungsvariable BAWCRS gesetzt wurde, deren Inhalt zur Ermittlung des CRS der Eingangsdatei herangezogen, falls bisher kein CRS in der Datei vorhanden war.
  • Beim Dateiformat 16 (World-Datei) werden auch die die Pixelgröße und Orientierung beschreibenden Parameter affin transformiert. Dazu wird ein imaginäres Image der Größe 800x800 Pixel aufgespannt und daraus die neuen mittleren Werte für die Pixelbreite und -höhe ermittelt.
  • Alle nicht NAMELIST-basierten ASCII-Formate enthalten nach der Transformation einen aus Kommentaren bestehenden Dateikopf mit der aktuellen Koordinatentransformation.
  • 7- und 8-stellige Rechtswerte in UTM-Koordinaten werden erkannt und in 6-stellige Rechtswerte umgewandelt. Zur Erkennung gültiger 8- und 7-stelliger Rechtswerte wird sowohl die Anzahl der Stellen, als auch der UTM-Streifen der Eingabedatei verwendet.

Von libgeodesy werden die folgenden Koordinatenreferenzsysteme über den EPSG-Code unterstützt:

  • Gauß-Krüger 3 Grad / DHDN: EPSG 31466-31469 ( EPSG = 31464 + Streifennummer )
  • Gauß-Krüger 3 Grad / STN : EPSG 02398-02399
  • UTM / ETRS89  : EPSG 25828-25838 ( EPSG = 25800 + Zone )
  • UTM / ED50  : EPSG 23028-23038 ( EPSG = 23000 + Zone )
  • UTM / WGS84  : EPSG 32601-32660 ( EPSG = 32600 + Zone )
  • UPS / WGS84  : EPSG 32661 und 32761
  • RD Amersfoort New  : EPSG 28992
  • Geographisch ETRS89  : EPSG 4258
  • Geographisch WGS84  : EPSG 4326
  • Geographisch ED 50  : EPSG 4230
  • Geographisch DHDN  : EPSG 4314
  • Geographisch Amersfoort  : EPSG 4289

Es wird empfohlen, das Koordinatenreferenzsystem in Form des EPSG-Codes in den Datengrundlagen (Rohdaten) abzulegen, wenn bekannt. Dies kann bei den meisten ASCII-Dateitypen über den "magischen Kommentar" geschehen. Dort wo bereits innerhalb des Datenformates eine Möglichkeit vorgesehen ist, den EPSG-Code abzulegen, sollte dies auch passieren.

Neuere Datenbestände sollten immer in UTM/ETRS89-Koordinaten des jeweils gültigen Streifens oder in geographischen Koordinaten (ETRS89 oder WGS84) vorgehalten werden. Für die Transformation älterer Datenbestände aus Gauß-Krüger nach UTM/ETRS-89 soll das NTv2-Verfahren nach GNTRANS-WSV genutzt werden. Das Gitter deckt allerdings nur das Bundesgebiet einschließlich der Hoheitsgewässer ab. Koordinaten die außerhalb des Gültigkeitsbereiches der Transformationsgitter liegen, sollten nicht mit NTv2, sondern einer geeigneten Helmert-Transformation transformiert werden.

Koordinatentransformation ist keine triviale Aufgabe. Daher sollte das Ergebnis einer Transformation immer auf Richtigkeit und Weiterverwendbarkeit geprüft werden.

Vorlauf-Programme

Alle Programme, die obige Dateiformate nutzen

Nachlauf-Programme

Alle Programme, die obige Dateiformate nutzen

Weitere Informationen

Programmiersprache

Fortran95

zusätzliche Software

NTv2-Gitter dhdn_to_etrs89_wsv_v1.gsb, stn_to_etrs89_wsv_v1.gsb und BETA2007.gsb

Originalversion

G. Seiß (Hauptprogramm, Datei-I/O, libgeodesy)

Programmpflege

G. Seiß

Dokumentation/Literatur

interaktiv selbsterklärend
$PROGHOME/examples/geotransformer
Junkins, D.R. and Farley, S.A. (1995) National Transformation version 2 Users Guide, Geodetic Survey Division Geomatics Canada
Lott, Roger und OGP Geodesy Working Group (2015) Coordinate Conversions and Transformations including Formulas. Geomatics Guidance Note (IOGP Publication 373), 7. Part 2.


zurück zu Programmkennblätter


Strukturübersicht