Das Format GeoJson ist gut geeignet, um punkt-, linien- und fl\u00e4chenf\u00f6rmige Objekte mit Attributen zu \u00fcbertragen. 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.<\/p>\n\n\n\n
Dabei entsteht leider eine Unsch\u00e4rfe. W\u00fcrde man sich nach der exakten Spezifikation des Open Geospatial Consortium (OGC) f\u00fcr GeoJson richten, m\u00fcssten die Koordinaten in L\u00e4ngen- und Breitengraden bezogen auf WGS84 \u00fcbergeben werden.<\/p>\n\n\n\n
Das ist aber sehr unpraktisch, weil bei Erfassung der Daten per Drohne und sp\u00e4terer Auswertung zur Georeferenzierung ein Korrekturdienst wie SAPOS im Spiel war und die Daten sind bereits auf unser europ\u00e4isches ETRS89 bezogen.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
In der Seefahrt ist eine Differenz von knapp einem Meter kein Problem, in der Bauvermessung schon.<\/p>\n\n\n\n
Bis 2008 gab es in der GeoJson-Spezifikation ein Objekt \u201ecrs\u201c (Coordinate Reference System) mit dem EPSG-Code des verwendeten Koordinatensystem, hier 4258 (ETRS89):
„crs“: {
„type“: „Name“,
„properties“: {
„name“: „urn:ogc:def:crs:EPSG::4258“
}
}<\/p>\n\n\n\n
Der segensreiche EPSG-Code der \u201eEuropean Petroleum Survey Group Geodesy\u201c beschreibt mittels einer Ganzzahl eindeutig das verwendete Koordinatensystem.<\/p>\n\n\n\n
Leider wurde diese wichtige Information in 2008 aus der Spezifikation entfernt, angeblich weil die beim Import notwendigen Transformationen oder Projektionen zu fehleranf\u00e4llig seien.<\/p>\n\n\n\n
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\u00e4re blanker Unsinn.<\/p>\n\n\n\n
Eine GeoJson ohne crs-Objekt in ETRS89 zu \u00fcbergeben, widerspricht der Spezifikation, das obige CRS-Objekt zu \u00fcbergeben auch.<\/p>\n\n\n\n
Saubere Prozesse im Rahmen der Digitalisierung erfordern Eindeutigkeit. Hier hat das Open Geospatial Consortium uns f\u00fcr das Bauwesen in Europa leider einen Stein in den Weg gelegt.<\/p>\n\n\n\n
Wir als isl – kocher pl\u00e4dieren daf\u00fcr, das crs-Objekt weiterhin zu \u00fcbergeben 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
Das Format GeoJson ist gut geeignet, um punkt-, linien- und fl\u00e4chenf\u00f6rmige Objekte mit Attributen zu \u00fcbertragen. 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\u00e4rfe. W\u00fcrde man sich nach der exakten Spezifikation des Open Geospatial Consortium (OGC) f\u00fcr GeoJson richten, m\u00fcssten die Koordinaten in L\u00e4ngen- und Breitengraden bezogen auf WGS84 \u00fcbergeben werden. Das ist aber sehr unpraktisch, weil bei Erfassung…<\/p>\n