Apache SIS: EPSG Koordinaten umrechnen (und mehr)

Eine der – für die meisten – weniger schönen Beschäftigungen im Umfeld von GPS/GNSS ist die Umwandlung von Koordinaten von einem “Coordinate Reference System” (CRS) in ein anderes. Im Allgemeinen sprechen die Receiver WGS84. Das genügt auch solange man die Daten nicht mit anderen Systemen austauschen oder abgleichen möchte.

Unter EPSG versteht man einen einheitlichen Standard von Coordinate Reference Systems. Derzeit sind knapp 6000 solcher Systeme gebräuchlich. Wahrscheinlich gibt es jedoch noch wesentlich mehr, die nicht veröffentlicht wurden. Entwickelt wurde das System im Rahmen einer Arbeitsgruppe der International Association of Oil & Gas Producers und firmiert unter dem Namen “European Petroleum Survey Group Geodesy“.

Unter der Katalognummer EPSG 4326 verbirgt sich zum Beispiel das genannte WGS84. Andere Systeme, wie Gauss-Krüger mit verschiedenen Anpassungen an die jeweiligen Breiten und Längen sind zum Beispiel in Deutschland gültig.

Ein typischer Fall für die Konversion verschiedener Koordinatensystem ist beispielsweise die Gebäude-Datenbank des österreichischen Bundesamt für Eich- und Vermessungswesen. in mehreren Excel-Dateien (sic!) sind Strassen, Hausnummern und Gebäudetypen aller österreichischen Bundesländer(!) aufgelistet. Zusätzlich ist jedes Gebäude auch mit einer (Punkt-)Koordinate verzeichnet.

Die Koordinaten sind dabei allerdings in zwei verschiedenen CRS gelistet: EPSG 31255 und EPSG 31266. D.h. bei einer Konversion genügt nicht eine Formel sondern man benötigt mindestens zusätzliche Variablen.

Mit Hilfe der Apache SIS Bibliothek steht ein Java-Framework zur Verfügung, dass die EPSG-Spezifikationen lesen kann und Konversionen von über 5000 Systemen durchführen kann.

ps: Neben der bemerkenswerten Tatsache, dass Österreich offensichtlich in Sachen “Offene Daten” ein Vorreiter ist, muss man geoland.at erwähnen. Dort kann man unter anderem Gauss-Krüger-Daten verschiedener CRS eintragen und sich auf der Karte anzeigen lassen.

 

Die Höhenvermessung der Welt: OpenDEM

Ein Kommentar zu “Android N mit Zugriff auf Raw GPS Data?” verwies auf ein uns bisher unbekanntes Projekt zur Höhenvermessung der Welt mit Hilfe der Crowd. OpenDEM startete bereits 2011 und möchte mit verschiedenen Methoden eine offene Quelle für Höhen- und Tiefenangaben aufbauen.

Neben App und Mapeditor bietet das Projekt Links zu frei verfügbaren Daten und interessante Informationen aus dem Bereich.

Aufbau einer ersten Testumgebung

In den nächsten Wochen soll es einen ersten Test für die grundlegenden Funktionen von OpenDGPS geben. Eine mobile Station soll mit Hilfe eines RTL-Dongles die Korrekturdaten für die eigene Position ermitteln und diese via Ntrip (Server, Caster & Client sind hier verfügbar) an eine entfernte Station senden, die die Differential-Daten verwendet um die eigene Positionsgenauigkeit zu verbessern. Ein Vergleichs-Receiver an dieser Station dient dazu, die Verbesserung bei verschiedenen Situationen (delay, Wetter) zu vergleichen.

Testsetup mit einer Basisstation und einem "Rover"

Testsetup mit einer Basisstation und einem “Rover”

Die Distanz beider Stationen beträgt 3,63km und beide sind an einer dauerhaften DSL-Verbindung am Netz.

Setup Basis:

Die Basisstation besteht aus einem parallella mit einem Dual Core ARM A9 auf Basis eines Zynq7020 und einem 16 Core Epiphany SMP. Sowohl die Programming Logic als auch der Multicore-Prozessor kommen im ersten Schritt nicht zum Einsatz. Später soll möglicherweise der FPGA des Zynqs einige Operationen des RTL-SDR-Parts (z.B. via GPS Demystified) oder/und RTKLIB übernehmen.

Als Receiver für die GPS Daten kommt ein einfacher 10€ DAB+ Dongle mit RTL-Chip zum Einsatz. Auf dem SDR-GPS-Blog von Peter Hahn findet sich eine Anleitung, wie man mit Hilfe von GNURadio an die GNSS-Daten gelangt.

Die Korrekturdaten sollen mit Hilfe des NTRIP-Protokolls (über einen Proxy) veröffentlicht werden. Die interessante Frage ist erstens, wie zeitnah ein 1GHz Dual Core ARM die Daten mit Hilfe der RTKLIB berechnen kann und zweitens, wie zeitnah die Daten tatsächlich für welche Genauigkeit beim Rover sein müssen. Es ist klar, dass je aktueller die Differential-Daten tatsächlich sind, desto genauer wird die Korrektur sein. Möglicherweise genügt jedoch eine Update-Frequenz von Minuten um eine signifikante Steigerung der Genauigkeit zu erlangen. Zumal in dem Testsetup vorerst nur eine feste Station die Daten liefert.

Für den Test ist nicht vorgesehen, die Basisstation aufwendig zu eichen. Es soll lediglich eine mehrere Stunden dauernde Korrektur vorgenommen werden um eine annähernde Genauigkeit zu erreichen. Da die Station nicht bewegt wird dürfte sich die Ungenauigkeit an dieser Stelle nicht auf die Qualität der Korrekturdaten auswirken.

Setup “Rover”:

Der Rover ist in unserem Test keine bewegliche Einheit sondern ein stationäres System. Es soll zunächst nur dazu dienen, den Gewinn an Genauigkeit zu definieren. Es wird ein UDOO Quad Core verwendet. Das UDOO verfügt neben einem normalen ARM-System auch über eine Arduino-Einheit die uns die benötigten I/Os bietet. Als GPS-Receiver kommen zwei NaviLock NL 507E TTL zum Einsatz. Der darin verbaute u-blox kann mit NTRIP-Daten umgehen und sie zur Korrektur verwenden.

Dabei soll der nur einer der beiden Receiver die Korrekturdaten erhalten. Der andere Empfänger verwendet nur die onboard Positionierung. Dadurch können die beiden Daten verglichen werden und hoffentlich die Unterschiede in der Genauigkeit sichtbar werden.

Auf dem Rover-System läuft keine RTKLIB, die NMEA-Daten werden lediglich über TTL zur späteren Analyse gespeichert.

Update

OpenDGPS hat sich einige Zeit in einem Hybernation-Modus befunden. Aus privaten Gründen konnte sich kein Unterstützer darum kümmern. Wir hoffen dem Projekt nun wieder Schwung geben zu können.

Zunächst werden wir uns darum kümmern, ein Wiki und/oder eine Mailinglist in Betrieb nehmen zu können. Hilfe ist wie immer willkommen.