Das Format GeoJson ist gut geeignet, um punkt-, linien- und flächenförmige Objekte mit Attributen zu übertragen. Unser isl- baustellenmanager kann solche Dateien im- und exportieren.
Der Import dient in der Regel zur Weiterverarbeitung von Objekten, die aus Punktwolken (Drohnendaten) gewonnen wurden.

Dabei entsteht leider eine Unschärfe. Würde man sich nach der exakten Spezifikation des Open Geospatial Consortium (OGC) für GeoJson richten, müssten die Koordinaten in Längen- und Breitengraden bezogen auf WGS84 übergeben werden.

Das ist aber sehr unpraktisch, weil bei Erfassung der Daten per Drohne und späterer Auswertung zur Georeferenzierung ein Korrekturdienst wie SAPOS im Spiel war und die Daten sind bereits auf unser europäisches ETRS89 bezogen.

Bekanntlich war zum 1.1.1989 WGS84 und ETRS89 praktisch gleich, auf Grund der Kontinentaldrift von Europa nach Nordosten unterscheiden sich die Koordinaten heute um knapp einen Meter.

In der Seefahrt ist eine Differenz von knapp einem Meter kein Problem, in der Bauvermessung schon.

Bis 2008 gab es in der GeoJson-Spezifikation ein Objekt „crs“ (Coordinate Reference System) mit dem EPSG-Code des verwendeten Koordinatensystem, hier 4258 (ETRS89):
„crs“: {
„type“: „Name“,
„properties“: {
„name“: „urn:ogc:def:crs:EPSG::4258“
}
}

Der segensreiche EPSG-Code der „European Petroleum Survey Group Geodesy“ beschreibt mittels einer Ganzzahl eindeutig das verwendete Koordinatensystem.

Leider wurde diese wichtige Information in 2008 aus der Spezifikation entfernt, angeblich weil die beim Import notwendigen Transformationen oder Projektionen zu fehleranfällig seien.

Bereits auf ETRS89 korrigierte Daten nach WGS84 umzurechnen, nur um der Spezifikation zu entsprechen und zur Weiterverarbeitung sie wieder auf ETRS89 zu schieben und nach UTM zu projizieren, wäre blanker Unsinn.

Eine GeoJson ohne crs-Objekt in ETRS89 zu übergeben, widerspricht der Spezifikation, das obige CRS-Objekt zu übergeben auch.

Saubere Prozesse im Rahmen der Digitalisierung erfordern Eindeutigkeit. Hier hat das Open Geospatial Consortium uns für das Bauwesen in Europa leider einen Stein in den Weg gelegt.

Wir als isl – kocher plädieren dafür, das crs-Objekt weiterhin zu übergeben und schreiben die Information beim Export auch die die Datei.

Tests mit QGIS beispielsweise zeigten, dass die Information beim Import zumindest in dieses Geoinformationssystem auch korrekt verarbeitet wird.