Aktionen

GEOTRANSFORMER: Unterschied zwischen den Versionen

Aus BAWiki

imported>BAWiki 3
KKeine Bearbeitungszusammenfassung
K (EPSG-Codes für 8-stellige UTM-Koordinaten)
 
(62 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 2: Zeile 2:
|name_en=GEOTRANSFORMER
|name_en=GEOTRANSFORMER
|name=GEOTRANSFORMER
|name=GEOTRANSFORMER
|version=Oktober 2009
|version=Februar 2023
|version_beschr=Oktober 2009
|version_beschr=Februar 2023
|stichworte=Koordinaten-Transformation<br />
|stichworte=Koordinaten-Transformation<br />
Koordinaten-System<br />
Koordinaten-System<br />
Gauß-Krüger<br />
Gauß-Krüger<br />
Universale Transverse Mercator Projektion <br />
Universale Polar Stereografisch Projektion <br />
Lagestatus 320<br />
Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)<br />
Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)<br />
World Geodetic System 1984 (WGS84)<br />
World Geodetic System 1984 (WGS84)<br />
European Datum 1950 (ED50)<br />
European Datum 1950 (ED50)<br />
Potsdam Datum (Bessel 1841)<br />
Krassowski-Ellipsoid<br />
NTv2-Verfahren<br />
BETA2007<br />
GNTRANS-WSV<br />
Rijksdriehoeksmeting (RD, niederl. Koordinatensystem)<br />
Rijksdriehoeksmeting (RD, niederl. Koordinatensystem)<br />
BAW-Dateiformate  
BAW-Dateiformate<br />
European Petrol Service Group (EPSG)


|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 Kartenprojektionen und geodätischen Datumstransformationen. Die Beschreibung der Koordinatenreferenz wird vom Nutzer entweder über EPSG-Codes oder durch Angabe der Kartenprojektion und des geodätischen Datums übergeben.
Derzeit implementierte Koordinaten-Systeme sind:


* Gauß-Krüger (Streifen 2 bis 5)
Derzeit implementierte Kartenprojektionen sind:
* Geographische Koordinaten
* Universal Transverse Mercator (UTM)


Derzeit implementierte geodätische Datumstransformationen (Helmert-Transformationen) sind
* Gauß-Krüger (Streifen 2 bis 5), 3 Grad-Streifen oder 6-Grad-Streifen
* Sphärische Koordinaten (geografische Länge und Breite == keine Kartenprojektion)
* Universal Transverse Mercator (UTM)
* Rijksdatum (Niederlande)
* lokale metrische Zentralprojektion
* Universal Polar Stereographic (UPS)
* British National Grid
 
Derzeit implementierte geodätische Datumstransformationen (7-Parameter-Transformationen) sind


* Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)
* Europäisches Terrestrisches Referenzsystem 1989 (ETRS89)
Zeile 28: Zeile 42:
* Bundesamt für Kartographie und Geodäsie, Breiten >52,3 Grad N
* Bundesamt für Kartographie und Geodäsie, Breiten >52,3 Grad N
* BAW C. Maushake,
* BAW C. Maushake,
* Krassovsky Standard ([[Wikipedia]])
* Krassovsky Standard ([http://de.wikipedia.org/wiki/7-Parameter-Transformation Wikipedia])
* Krassovsky (WSA Stralsund)
* 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 niederländische Referenzdatum (Amersfoort Datum)
* Das Britische Elipsoid Airy 1830
* NTv2-Gitterverfahren GNTRANS-WSV (DHDN/STN -> ETRS89) und BETA2007 (DHDN -> ETRS89)
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 mit NTv2 280,68 Minuten inklusive Ein- und Ausgabe.
Seit November 2018 verfügt das Programm über die Fähigkeit, die Nutzereingaben über Kommandozeilenargumente entgegenzunehmen. Für diese Nutzung steht eine Online-Hilfe bereit, die mit '''''geotransformer -h''''' abgerufen wird.
Das Programm GEOTRANSFORMER ist seit Mai 2016 sowohl für die '''LINUX'''-Systeme als auch für '''WINDOWS''' ohne Einschränkung der Funktionalität verfügbar und wurde anhand offizieller Testkoordinaten für die verwendeten mathematischen Algorithmen validiert. Es existiert eine Kurzanleitung für Einsteiger.
Die vom Programm genutzte Bibiliothek '''libgeodesy''' wird auch in anderen Programmen genutzt, um Koordinaten "on the fly" zu transformieren. Es wurde ein in C geschriebenes "Application Programmer Interface" (API) '''libgeodesyCAPI''' bereitgestellt, um einen Port der Transformations-Funktionalität für MATLAB zu realisieren.


|eingabedateien=
|eingabedateien=
# Gitternetzdatei (Dateityp TICAD, [[GITTER05.DAT|gitter05.dat]] /[[GITTER05.BIN/gitter05.bin]]) oder
# Gitternetzdatei (Dateityp TICAD,[[GITTER05.DAT und GITTER05.BIN|gitter05.dat/bin]]) oder
# UnTRIM-VC-Gitternetzdatei (Dateityp untrim_grid.dat) oder
# digitalisierte Linien (Dateityp [[DIGI.GKK|digi.gkk]]) oder
# Peildatendatei (Dateityp geom.dat) oder
# digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp [[INSEL.DAT|insel.dat]]) oder
# Geopositionsdatei (Dateityp geopos.dat) oder
# Polygondateien (Dateityp [[POLY.DAT|poly.dat]]) oder
# digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp insel.dat) oder
# Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp [[NODES.SAVE|nodes.save]]) oder
# digitalisierte Linien (Dateityp digi.gkk) oder
# (Dateityp [[FRAMES.DAT|frames.dat]], der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
# Polygondateien (Dateityp poly.dat) oder
# Beschreibung der Randgitterzellen (Dateityp [[RGZ.DAT|rgz.dat]]) oder
# Zeitreihendateien an Einzelstationen (Dateityp boewrt.dat) oder
# ASCII-Format für Punktdaten, Peildatendatei (Dateityp [[GEOM.DAT|geom.dat]]) oder
# Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp nodes.save) oder
# Zeitreihendateien an Einzelstationen (Dateityp [[BOEWRT.DAT|boewrt.dat]]) oder
# (Dateityp frames.dat, der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
# Geopositionsdatei (Dateityp [[GEOPOS.DAT|geopos.dat]]) oder
# Beschreibung der Randgitterzellen (Dateityp rgz.dat).
# UNTRIM-VC-Gitternetzdatei (Dateityp [[UNTRIM_GRID.DAT|untrim_grid.dat]], Variante Vincento Casulli) oder
# DELFT3D-Gitternetzdatei (Dateityp [[DELFT3D.GRD|delft3d.grd]]) oder
# UNTRIM-BAW-Gitternetzdatei (Dateityp [[UNTRIM_GRID.DAT|untrim_grid.dat]], Variante BAW) oder
# Systemdatei für Einzelpositionen (Dateityp [[LOCATION_GRID.DAT|location_grid.dat]]) oder
# IPDS-Datei zur Initialisierung von Anfangsfeldern (Dateityp [[IPDS.DAT|ipds.dat]]) oder
# World-Datei zur Beschreibung der Georeferenzierung eines Images (typische Datei-Endungen sind ''.pngw, .jpgw, .gifw'') oder
# Profilgitter (Dateityp [[PROFIL05.BIN|profil05.bin]] oder
# durch Semikolon ( ; ), Tabulator (\t), Leerzeichen oder Doppelpunkt (:) getrennte CSV-Tabelle ("comma seperated values") oder
# Indizierte Punktdaten (Index, Rechtswert/Länge, Hochwert/Breite, z).


|ausgabedateien=
|ausgabedateien=
# Gitternetzdatei (Dateityp TICAD, gitter05.dat/gitter05.bin) oder
# Gitternetzdatei (Dateityp TICAD,[[GITTER05.DAT und GITTER05.BIN|gitter05.dat/bin]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# UnTRIM-VC-Gitternetzdatei (Dateityp untrim_grid.dat) oder
# digitalisierte Linien (Dateityp [[DIGI.GKK|digi.gkk]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# Peildatendatei (Dateityp geom.dat) oder
# digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp [[INSEL.DAT|insel.dat]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# Geopositionsdatei (Dateityp geopos.dat) oder
# Polygondateien (Dateityp [[POLY.DAT|poly.dat]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp insel.dat) oder
# Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp [[NODES.SAVE|nodes.save]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# digitalisierte Linien (Dateityp digi.gkk) oder
# (Dateityp [[FRAMES.DAT|frames.dat]], der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
# Polygondateien (Dateityp poly.dat) oder
# Beschreibung der Randgitterzellen (Dateityp [[RGZ.DAT|rgz.dat]]) oder
# Zeitreihendateien an Einzelstationen (Dateityp boewrt.dat) oder
# ASCII-Format für Punktdaten, Peildatendatei (Dateityp [[GEOM.DAT|geom.dat]]) oder
# Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp nodes.save) oder
# Zeitreihendateien an Einzelstationen (Dateityp [[BOEWRT.DAT|boewrt.dat]]) und je eine (optional) Datei des Typs [[GEOPOS.DAT|geopos.dat]] oder
# (Dateityp frames.dat, der Centerpunkt und die Abmessungen werden innerhalb von metrischen Systemen transformiert) oder
# Geopositionsdatei (Dateityp [[GEOPOS.DAT|geopos.dat]]) oder
# Beschreibung der Randgitterzellen (Dateityp rgz.dat). Datei ist nur bedingt weiterverwendbar, da FD-Netze nicht exakt transformiert werden können.
# UNTRIM-VC-Gitternetzdatei (Dateityp [[UNTRIM_GRID.DAT|untrim_grid.dat]], Variante Vincento Casulli) oder
# DELFT3D-Gitternetzdatei (Dateityp [[DELFT3D.GRD|delft3d.grd]]) oder
# UNTRIM-BAW-Gitternetzdatei (Dateityp [[UNTRIM_GRID.DAT|untrim_grid.dat]], Variante BAW) oder
# Systemdatei für Einzelpositionen (Dateityp [[LOCATION_GRID.DAT|location_grid.dat]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# IPDS-Datei zur Initialisierung von Anfangsfeldern (Dateityp [[IPDS.DAT|ipds.dat]]) und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# World-Datei zur Beschreibung der Georeferenzierung eines Images (typische Datei-Endungen sind ''.pngw, .jpgw, .gifw'') oder
# Profilgitter (Dateityp [[PROFIL05.BIN|profil05.bin]] und (optional) Dateien des Typs [[GEOPOS.DAT|geopos.dat]] oder
# durch Semikolon ( ; ), Tabulator (\t), Leerzeichen oder Doppelpunkt (:) getrennte CSV-Tabelle ("comma seperated values") oder
# Indizierte Punktdaten (Index, Rechtswert/Länge, Hochwert/Breite, z).
 
|methode=
*  Ein- und Ausgabe-Datei sind zeitgleich geöffnet. Jeder gelesene Koordinaten-Punkt wird sofort transformiert und in die Ausgabe-Datei geschrieben. Dadurch kann die Anzahl der zu transformierenden Koordinaten in der Eingangs-Datei beliebig groß sein. Kommentarzeilen in ASCII-Dateien werden übernommen. Die Eingabe-Datei darf in gepackter Form (gzip, compress, zip) vorliegen. Ein Packen der Ausgabedatei kann durch Angabe des Dateinamens mit zusätzlich angehängter Dateiendung ".gz" oder ."zip" erzwungen werden (letzteres derzeit nur unter LINUX).
* 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 (für die alten Bundesländer 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 ASCII-Zeichen Tabulator, Semikolon, Komma und Doppelpunkt erlaubt. Außerdem dürfen geographische Koordinaten in der nautischen Form 4°17'16.62931"E 51°29'40.02423"N angegeben werden. Statt der Zeichen (° ' ") sind auch (d m s) oder (^ ' ") erlaubt. Die nautische Form muss mit den Angaben der Hemisphere(N/S) und der Lage bezogen auf Greenwich (E/W) versehen sein.
* Bei den Dateiformaten 09 ([[BOEWRT.DAT|boewrt.dat]]), 10 (geopos.dat), 13 ([[UNTRIM_GRID.DAT|untrim_grid.dat]], Variante BAW) und 14 ([[LOCATION_GRID.DAT|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|untrim_grid.dat]], Variante BAW) und 14 ([[LOCATION_GRID.DAT|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.
* Für einige Dateitypen ist eine optionale Ausgabe aller Original-Koordinaten als Dateien des Typs [[GEOPOS.DAT|geopos.dat]] möglich. Diese Dateien können zur Kontrolle genutzt werden oder im Pre-Prozessing Verwendung finden (z.B. in [[TICLQ2]]).
* Beim Dateityp 18 können die zu bearbeitenden Spalten frei vom Nutzer gewählt werden und mit den Horizontalkoordinaten kann jeweils eine Spalte mit zugehörigen Höhenwerten beim Datumsübergang transformiert werden. Es dürfen mehrere Koordinatenpaare/-tripel in einer Zeile gleichzeitig transformiert werden. Das Spaltentrennzeichen ist zunächst Semikolon. Wird keines gefunden, so werden alternativ in der Reihenfolge Tabulator, Leerzeichen und Doppelpunkte gesucht. Kommas in den Dezimalwerten werden erkannt und in "." gewandelt. Der Spaltentrenner wird beibehalten, Dezimalkomma werden immer in Dezimalpunkt gewandelt.


Alle Transformationsalgorithmen nutzen doppelt genaue Fließkommawerte zur Darstellung der Koordinaten im Speicher. In den zwei unterstützten binären Dateiformaten [[GITTER05.DAT und GITTER05.BIN|gitter05.bin]] und [[PROFIL05.BIN|profil05.bin]] werden einfachgenaue REAL-Werte der Koordinaten abgelegt. Diese Formate sind '''zumindest mit Vorsicht''' zu nutzen, denn sphärische Koordinaten können nur mit erheblichem Genauigkeitsverlust geschrieben werden:
* [[GITTER05.DAT und GITTER05.BIN|gitter05.dat/bin]]: Hier wird empfohlen, die ASCII-Variante GITTER05.DAT zu erzeugen und zukünftig nur noch damit zu arbeiten!
* [[PROFIL05.BIN|profil05.bin]]: Hier wird empfohlen, nur in projezierten Koordinaten zu schreiben (UTM, Gauß-Krüger). Die erreichbare Genauigkeit der Koordinatendarstellung beträgt in projezierten Koordinaten 0,5-1m.
Bei den unterstützten ASCII-Dateiformaten wird die Genauigkeit der Koordinatendarstellung abhängig vom Koordinatenreferenzsystem so gewählt, dass im Regelfall kein Genauigkeitsverlust eintritt, wenn sphärische Koordinaten verwendet werden.
Von libgeodesy werden die folgenden Koordinatenreferenzsysteme über den EPSG-Code unterstützt:
* Gauß-Krüger 3 Grad / DHDN: EPSG 31466-31469 ( EPSG = 31464 + Streifennummer ), verwendetes Ellipsoid BKG >52,3 Grad N
* Gauß-Krüger 3 Grad / STN : EPSG 02397-02399, 05674-05675, 03838, 03829
* Lagestatus 320 (Bundesland Hamburg, Gauß-Krüger/ETRS89, Streifen 3): EPSG 8395
* Gauß-Krüger 3 Grad / DHDN: EPSG 31462-31465 ( EPSG = 31460 + Streifennummer ), zweckentfremdet für Datum BKG zwischen 50,3 Grad N und 52,3 Grad N
* Gauß-Krüger 3 Grad / DHDN: EPSG 31492-31495 ( EPSG = 31490 + Streifennummer ), zweckentfremdet für Datum BKG <50,3 Grad N
* UTM / ETRS89            : EPSG 25828-25838 ( EPSG = 25800 + Zone )
* UTM / ETRS89, 8-stellig  : 4647, 5649, 5650, 35832, 35833
* UTM / ED50              : EPSG 23028-23038 ( EPSG = 23000 + Zone )
* UTM / WGS84 (Nord)      : EPSG 32601-32660 ( EPSG = 32600 + Zone )
* UTM / WGS84 (Süd)        : EPSG 32701-32760 ( EPSG = 32700 + Zone )
* UPS / WGS84              : EPSG 32661 und 32761
* RD Amersfoort New        : EPSG 28992 und 7415
* OSGB 1936/British National Grid: EPSG 27700
* Geographisch ETRS89      : EPSG 04258
* Geographisch WGS84      : EPSG 04326
* Geographisch ED 50      : EPSG 04230
* Geographisch DHDN        : EPSG 04314
* Geographisch Amersfoort  : EPSG 04289
* Geographisch STN42/83    : EPSG 04179
Einige andere, nicht über EPSG-Codes unterstützte Koordinatenreferenzsysteme können derzeit im sogenannten Expertenmodus (Basiswissen über Lagebezugssysteme nötig) realisiert werden.
Es wird empfohlen, das Koordinatenreferenzsystem in Form des EPSG-Codes in den Datengrundlagen (Rohdaten) abzulegen, wenn bekannt und unterstützt. Dies kann bei den meisten ASCII-Dateitypen über den magischen Kommentar "C CRS=#####" geschehen. Dort wo bereits innerhalb des jeweiligen 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. Im Zweifel sollte vom Urheber der Koordinaten immer das zugehörige Koordinatenreferenzsystem bereitgestellt werden.
Koordinatentransformation ist '''keine triviale Aufgabe'''. Daher sollte das Ergebnis einer Transformation immer auf Plausibilität und Weiterverwendbarkeit geprüft werden. Bei häufigem Hin- und Rücktransformieren akkumulieren sich zwangsläufig vorhandene numerische Fehler in den zugrundeliegenden Algorithmen.


|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.
|preprozessor=Alle Programme, die obige Dateiformate nutzen  
|preprozessor=Alle Programme, die obige Dateiformate nutzen  
|postprozessor=Alle Programme, die obige Dateiformate nutzen  
|postprozessor=Alle Programme, die obige Dateiformate nutzen  
|programmiersprache=Fortran90
|programmiersprache=Fortran2003, C
|zus_software= -  
|zus_software= NTv2-Gitter DHDN_To_ETRS1989_WSV2020_v3.gsb, STN_To_ETRS1989_WSV2020_v2.gsb (oder ältere) und BETA2007.gsb
|kontakt_original=[mailto:guntram.seiss@baw.de G. Seiß] (Hauptprogramm, Datei-I/O)  
|kontakt_original=G. Seiß  (Hauptprogramm, Datei-I/O, libgeodesy)  
|kontakt_pflege=[mailto:guntram.seiss@baw.de G. Seiß]
|kontakt_pflege=[mailto:pre.proghome@baw.de Arbeitsgruppe PRE]
|dokumentation=interaktiv selbsterklärend  
|dokumentation=interaktiv selbsterklärend<br/> $PROGHOME/examples/geotransformer/*<br/> $PROGHOME/examples/geotransformer/Anleitung_GEOTRANSFORMER.pdf <br/> Junkins, D.R. and Farley, S.A. (1995) '''N'''ational '''T'''ransformation '''v'''ersion '''2''' Users Guide, Geodetic Survey Division Geomatics Canada. <br/>
Lott, Roger und OGP Geodesy Working Group (2015) Coordinate Conversions and Transformations including Formulas. [http://www.iogp.org/pubs/373-07-2.pdf Geomatics Guidance Note (IOGP Publication 373), 7. Part 2]. <br/>
Bruijne, Arnoud de; van Buren, Joop; Kösters, Anton; van der Marel, Hans (2005): De geodetische referentiestelsels van Nederland. Geodetic reference frames in the Netherlands. Hg. v. Nederlandse Commissie voor Geodesie Netherlands Geodetic Commission. Delft. [http://www.ncgeo.nl/index.php?option=com_k2&view=item&id=2361:gs-43-a-de-bruijne-de-geodetische-referentiestelsels-van-nederland&Itemid=178&lang=nl Download hier]. <br/>
Wasserstraßen- und Schifffahrtsverwaltung des Bundes (Hg.) (2012): Handlungsanweisung für die Transformation der Datenbestände der WSV in das System ETRS89/UTM. Unter Mitarbeit von Hendrik Hampe, Sudau, Gunther Braun, Cornelius Zschunke, Egon Feigel, Helga Panknin et al. <br/>
Lutter, H. (2009): Helmerttransformationsparameter für Gauss-Krüger Streifen 4 (Krassowski), WSA Stralsund. Pers. Mitteilung.
 
}}
}}

Aktuelle Version vom 27. Februar 2023, 14:15 Uhr

Basisinformationen

Programm-Name

GEOTRANSFORMER

Version

Februar 2023

Beschreibung

Februar 2023

Stichworte

Koordinaten-Transformation
Koordinaten-System
Gauß-Krüger
Universale Transverse Mercator Projektion
Universale Polar Stereografisch Projektion
Lagestatus 320
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
European Petrol Service Group (EPSG)

Kurzbeschreibung

Dieses Programm transformiert für verschiedenen Dateiformate der BAW die Koordinaten zwischen verschiedenen Kartenprojektionen und geodätischen Datumstransformationen. Die Beschreibung der Koordinatenreferenz wird vom Nutzer entweder über EPSG-Codes oder durch Angabe der Kartenprojektion und des geodätischen Datums übergeben.

Derzeit implementierte Kartenprojektionen sind:

  • Gauß-Krüger (Streifen 2 bis 5), 3 Grad-Streifen oder 6-Grad-Streifen
  • Sphärische Koordinaten (geografische Länge und Breite == keine Kartenprojektion)
  • Universal Transverse Mercator (UTM)
  • Rijksdatum (Niederlande)
  • lokale metrische Zentralprojektion
  • Universal Polar Stereographic (UPS)
  • British National Grid

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 niederländische Referenzdatum (Amersfoort Datum)
  • Das Britische Elipsoid Airy 1830
  • NTv2-Gitterverfahren GNTRANS-WSV (DHDN/STN -> ETRS89) und BETA2007 (DHDN -> ETRS89)

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 mit NTv2 280,68 Minuten inklusive Ein- und Ausgabe.

Seit November 2018 verfügt das Programm über die Fähigkeit, die Nutzereingaben über Kommandozeilenargumente entgegenzunehmen. Für diese Nutzung steht eine Online-Hilfe bereit, die mit geotransformer -h abgerufen wird.

Das Programm GEOTRANSFORMER ist seit Mai 2016 sowohl für die LINUX-Systeme als auch für WINDOWS ohne Einschränkung der Funktionalität verfügbar und wurde anhand offizieller Testkoordinaten für die verwendeten mathematischen Algorithmen validiert. Es existiert eine Kurzanleitung für Einsteiger.

Die vom Programm genutzte Bibiliothek libgeodesy wird auch in anderen Programmen genutzt, um Koordinaten "on the fly" zu transformieren. Es wurde ein in C geschriebenes "Application Programmer Interface" (API) libgeodesyCAPI bereitgestellt, um einen Port der Transformations-Funktionalität für MATLAB zu realisieren.

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 profil05.bin oder
  18. durch Semikolon ( ; ), Tabulator (\t), Leerzeichen oder Doppelpunkt (:) getrennte CSV-Tabelle ("comma seperated values") oder
  19. Indizierte Punktdaten (Index, Rechtswert/Länge, Hochwert/Breite, z).

Ausgabe-Dateien

  1. Gitternetzdatei (Dateityp TICAD,gitter05.dat/bin) und (optional) Dateien des Typs geopos.dat oder
  2. digitalisierte Linien (Dateityp digi.gkk) und (optional) Dateien des Typs geopos.dat oder
  3. digitalisierte Strukturlinien (Buhnen, Inseln, etc.) (Dateityp insel.dat) und (optional) Dateien des Typs geopos.dat oder
  4. Polygondateien (Dateityp poly.dat) und (optional) Dateien des Typs geopos.dat oder
  5. Polygone für die Sicherung von Tiefen an Knotenpunkten (Dateityp nodes.save) und (optional) Dateien des Typs geopos.dat 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) und je eine (optional) Datei des Typs geopos.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) und (optional) Dateien des Typs geopos.dat oder
  15. IPDS-Datei zur Initialisierung von Anfangsfeldern (Dateityp ipds.dat) und (optional) Dateien des Typs geopos.dat oder
  16. World-Datei zur Beschreibung der Georeferenzierung eines Images (typische Datei-Endungen sind .pngw, .jpgw, .gifw) oder
  17. Profilgitter (Dateityp profil05.bin und (optional) Dateien des Typs geopos.dat oder
  18. durch Semikolon ( ; ), Tabulator (\t), Leerzeichen oder Doppelpunkt (:) getrennte CSV-Tabelle ("comma seperated values") oder
  19. Indizierte Punktdaten (Index, Rechtswert/Länge, Hochwert/Breite, z).

Methode

  • Ein- und Ausgabe-Datei sind zeitgleich geöffnet. Jeder gelesene Koordinaten-Punkt wird sofort transformiert und in die Ausgabe-Datei geschrieben. Dadurch kann die Anzahl der zu transformierenden Koordinaten in der Eingangs-Datei beliebig groß sein. Kommentarzeilen in ASCII-Dateien werden übernommen. Die Eingabe-Datei darf in gepackter Form (gzip, compress, zip) vorliegen. Ein Packen der Ausgabedatei kann durch Angabe des Dateinamens mit zusätzlich angehängter Dateiendung ".gz" oder ."zip" erzwungen werden (letzteres derzeit nur unter LINUX).
  • 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 (für die alten Bundesländer 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 ASCII-Zeichen Tabulator, Semikolon, Komma und Doppelpunkt erlaubt. Außerdem dürfen geographische Koordinaten in der nautischen Form 4°17'16.62931"E 51°29'40.02423"N angegeben werden. Statt der Zeichen (° ' ") sind auch (d m s) oder (^ ' ") erlaubt. Die nautische Form muss mit den Angaben der Hemisphere(N/S) und der Lage bezogen auf Greenwich (E/W) versehen sein.
  • 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.
  • Für einige Dateitypen ist eine optionale Ausgabe aller Original-Koordinaten als Dateien des Typs geopos.dat möglich. Diese Dateien können zur Kontrolle genutzt werden oder im Pre-Prozessing Verwendung finden (z.B. in TICLQ2).
  • Beim Dateityp 18 können die zu bearbeitenden Spalten frei vom Nutzer gewählt werden und mit den Horizontalkoordinaten kann jeweils eine Spalte mit zugehörigen Höhenwerten beim Datumsübergang transformiert werden. Es dürfen mehrere Koordinatenpaare/-tripel in einer Zeile gleichzeitig transformiert werden. Das Spaltentrennzeichen ist zunächst Semikolon. Wird keines gefunden, so werden alternativ in der Reihenfolge Tabulator, Leerzeichen und Doppelpunkte gesucht. Kommas in den Dezimalwerten werden erkannt und in "." gewandelt. Der Spaltentrenner wird beibehalten, Dezimalkomma werden immer in Dezimalpunkt gewandelt.

Alle Transformationsalgorithmen nutzen doppelt genaue Fließkommawerte zur Darstellung der Koordinaten im Speicher. In den zwei unterstützten binären Dateiformaten gitter05.bin und profil05.bin werden einfachgenaue REAL-Werte der Koordinaten abgelegt. Diese Formate sind zumindest mit Vorsicht zu nutzen, denn sphärische Koordinaten können nur mit erheblichem Genauigkeitsverlust geschrieben werden:

  • gitter05.dat/bin: Hier wird empfohlen, die ASCII-Variante GITTER05.DAT zu erzeugen und zukünftig nur noch damit zu arbeiten!
  • profil05.bin: Hier wird empfohlen, nur in projezierten Koordinaten zu schreiben (UTM, Gauß-Krüger). Die erreichbare Genauigkeit der Koordinatendarstellung beträgt in projezierten Koordinaten 0,5-1m.

Bei den unterstützten ASCII-Dateiformaten wird die Genauigkeit der Koordinatendarstellung abhängig vom Koordinatenreferenzsystem so gewählt, dass im Regelfall kein Genauigkeitsverlust eintritt, wenn sphärische Koordinaten verwendet werden.

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

  • Gauß-Krüger 3 Grad / DHDN: EPSG 31466-31469 ( EPSG = 31464 + Streifennummer ), verwendetes Ellipsoid BKG >52,3 Grad N
  • Gauß-Krüger 3 Grad / STN : EPSG 02397-02399, 05674-05675, 03838, 03829
  • Lagestatus 320 (Bundesland Hamburg, Gauß-Krüger/ETRS89, Streifen 3): EPSG 8395
  • Gauß-Krüger 3 Grad / DHDN: EPSG 31462-31465 ( EPSG = 31460 + Streifennummer ), zweckentfremdet für Datum BKG zwischen 50,3 Grad N und 52,3 Grad N
  • Gauß-Krüger 3 Grad / DHDN: EPSG 31492-31495 ( EPSG = 31490 + Streifennummer ), zweckentfremdet für Datum BKG <50,3 Grad N
  • UTM / ETRS89  : EPSG 25828-25838 ( EPSG = 25800 + Zone )
  • UTM / ETRS89, 8-stellig  : 4647, 5649, 5650, 35832, 35833
  • UTM / ED50  : EPSG 23028-23038 ( EPSG = 23000 + Zone )
  • UTM / WGS84 (Nord)  : EPSG 32601-32660 ( EPSG = 32600 + Zone )
  • UTM / WGS84 (Süd)  : EPSG 32701-32760 ( EPSG = 32700 + Zone )
  • UPS / WGS84  : EPSG 32661 und 32761
  • RD Amersfoort New  : EPSG 28992 und 7415
  • OSGB 1936/British National Grid: EPSG 27700
  • Geographisch ETRS89  : EPSG 04258
  • Geographisch WGS84  : EPSG 04326
  • Geographisch ED 50  : EPSG 04230
  • Geographisch DHDN  : EPSG 04314
  • Geographisch Amersfoort  : EPSG 04289
  • Geographisch STN42/83  : EPSG 04179

Einige andere, nicht über EPSG-Codes unterstützte Koordinatenreferenzsysteme können derzeit im sogenannten Expertenmodus (Basiswissen über Lagebezugssysteme nötig) realisiert werden.

Es wird empfohlen, das Koordinatenreferenzsystem in Form des EPSG-Codes in den Datengrundlagen (Rohdaten) abzulegen, wenn bekannt und unterstützt. Dies kann bei den meisten ASCII-Dateitypen über den magischen Kommentar "C CRS=#####" geschehen. Dort wo bereits innerhalb des jeweiligen 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. Im Zweifel sollte vom Urheber der Koordinaten immer das zugehörige Koordinatenreferenzsystem bereitgestellt werden.

Koordinatentransformation ist keine triviale Aufgabe. Daher sollte das Ergebnis einer Transformation immer auf Plausibilität und Weiterverwendbarkeit geprüft werden. Bei häufigem Hin- und Rücktransformieren akkumulieren sich zwangsläufig vorhandene numerische Fehler in den zugrundeliegenden Algorithmen.

Vorlauf-Programme

Alle Programme, die obige Dateiformate nutzen

Nachlauf-Programme

Alle Programme, die obige Dateiformate nutzen

Weitere Informationen

Programmiersprache

Fortran2003, C

zusätzliche Software

NTv2-Gitter DHDN_To_ETRS1989_WSV2020_v3.gsb, STN_To_ETRS1989_WSV2020_v2.gsb (oder ältere) und BETA2007.gsb

Originalversion

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

Programmpflege

Arbeitsgruppe PRE

Dokumentation/Literatur

interaktiv selbsterklärend
$PROGHOME/examples/geotransformer/*
$PROGHOME/examples/geotransformer/Anleitung_GEOTRANSFORMER.pdf
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.
Bruijne, Arnoud de; van Buren, Joop; Kösters, Anton; van der Marel, Hans (2005): De geodetische referentiestelsels van Nederland. Geodetic reference frames in the Netherlands. Hg. v. Nederlandse Commissie voor Geodesie Netherlands Geodetic Commission. Delft. Download hier.
Wasserstraßen- und Schifffahrtsverwaltung des Bundes (Hg.) (2012): Handlungsanweisung für die Transformation der Datenbestände der WSV in das System ETRS89/UTM. Unter Mitarbeit von Hendrik Hampe, Sudau, Gunther Braun, Cornelius Zschunke, Egon Feigel, Helga Panknin et al.
Lutter, H. (2009): Helmerttransformationsparameter für Gauss-Krüger Streifen 4 (Krassowski), WSA Stralsund. Pers. Mitteilung.

zurück zu Programmkennblätter

Strukturübersicht

Abgerufen von „https://wiki.baw.de/de/index.php?title=GEOTRANSFORMER&oldid=36115“