GeoJSON-Standard veröffentlicht

(https://xkcd.com/927/)

TobWen wrote:

Vor einigen Tagen wurde GeoJSON als Internet-Standard veröffentlicht: https://tools.ietf.org/html/rfc7946
Wenn man sich aber die Personen anschaut, welche hinter dem Standard stehen, sieht man alte Bekannte aus dem WebGIS-Bereich... Leider wird nun nur noch WGS84 unterstützt! Ich frage mich echt, was die dazu bewegt hat, sich auf ein festes CRS einzuschießen...

Punkt 4 lässt ja auch noch ein Hintertürchen offen:

However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

Die Begründung finde ich nicht schlecht:

In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters.

Ich finde, damit ändert sich die derzeit übliche Praxis nicht: Jeder denkt, dass da immer Längen- und Breitengrade drin sein müssen und nimmt stillschweigend WGS84 an. Aber wenn man sich einig ist, darf man auch was anderes verwenden.

TobWen wrote:

Okay, Alternativen her!

GML?

Grüße
Max

maxbe wrote:

GML?

Genau! Das ist die Richtung, in die der Weg geht.

Gruss
walter

maxbe wrote:

Ich finde, damit ändert sich die derzeit übliche Praxis nicht: Jeder denkt, dass da immer Längen- und Breitengrade drin sein müssen und nimmt stillschweigend WGS84 an. Aber wenn man sich einig ist, darf man auch was anderes verwenden.

Ich finde das Argument, dass GeoJSON-verarbeitende Anwendungen keinen Zugriff auf CRS-Datenbanken haben schwach. GeoJSON wird entweder im Netz verwendet, wo jederzeit eine Verbindung aufgebaut werden kann oder man benutzt es offline im Datenaustausch oder lädt es in ein GIS, wo die benötigten Informationen standardmäßig vorhanden sind. Im Notfall könnte man die Beschreibung des CRS ja auch einfach mitliefern, wie bei den PRJ-Daten der Shapefiles.

Ich habe die schlimme Befürchtung, dass die Leute GeoJSON zukünftig nur noch mit WGS84 befeuern werden - selbst wenn auch andere Systeme möglich sind. Die meisten verbinden GeoJSON ja auch nur mit Online-Karten im Web Mercator 🙁

wambacher wrote:

Genau! Das ist die Richtung, in die der Weg geht.

Bitte sag, dass du das ironisch meinst. Du machst doch viel mit Websites - stell dir mal vor, du müsstest große XML-Daten dort parsen!

Und was für ein Chaos die INSPIRE-XML-Sachen sind, sieht man ja immer wieder (zuletzt bei den Bahn-Daten). Nur, weil XPlanung alle paar Jahre mal wieder in aller Munde ist, benutzt es trotzdem kaum einer 🙂

TobWen wrote:

wambacher wrote:

Genau! Das ist die Richtung, in die der Weg geht.

Bitte sag, dass du das ironisch meinst. Du machst doch viel mit Websites - stell dir mal vor, du müsstest große XML-Daten dort parsen!

Klar, GeoJson ist für Webseiten derzeit natürlich ideal, da man das Ergebnis direkt als Objekt in JavaScript verwenden kann, aber:

Null Problemo - wenn man die richtige Software verwendet. Die Zeiten, dass ich mich durch XML-Daten manuell - also mit selbst geschriebenen Software - durchackere, sind schon lange vorbei.

Server: http://GeoServer.org
GUI: https://qgis.org
Java: http://www.geotools.org/
JS: Leaflet mit Plugin http://moorespatial.com/tag/leaflet-js/
andere Sprachen: ?

gerade bei Leaflet erwarte ich noch erhebliche Verbesserungen, aber das Plugin schafft schon sehr viel.

Gruss
walter

TobWen wrote:

wambacher wrote:

Genau! Das ist die Richtung, in die der Weg geht.

Bitte sag, dass du das ironisch meinst. Du machst doch viel mit Websites - stell dir mal vor, du müsstest große XML-Daten dort parsen!

Und was für ein Chaos die INSPIRE-XML-Sachen sind, sieht man ja immer wieder (zuletzt bei den Bahn-Daten). Nur, weil XPlanung alle paar Jahre mal wieder in aller Munde ist, benutzt es trotzdem kaum einer 🙂

GML, INSPIRE und andere Sachen aus dem OGC-Bereich sind einfach "overengineered". Das ist alles so komplex, dass da niemand mehr durchsteigt. Vor allem sind diese Formate so ausgelegt, dass damit wirklich alle Sonderfälle angedeckt sind, wobei kaum ein Anwender all diese Features braucht. Für spezielle Anwendungen sind diese Standards OK, aber die Masse der Anwendungen braucht das nicht. Meiner Meinung bewirken solche komplexen Standards meist das Gegenteil von Vereinheitlichung: Weil die Spezifikationen so umfangreich sind, gibt es kaum eine Software, die das Format komplett unterstützt. Und das macht es dann alles noch komplizierter.

Allgemein ist es ja in technischen Bereichen so, dass sich immer die einfachen Dinge durchsetzen. Das ist der Grund, warum sich etwa HTTP oder TCP/IP so verbreitet haben, während sich etwa RDF und andere Ansätze des Semantic Web bis heute nicht durchsetzen konnten. Im Geo-Bereich sind Shapefiles ein de-facto Standard, weil sie sehr einfach aufgebaut sind und von praktisch jeder Anwendung unterstützt werden.

Gruß
Alex

rurseekatze wrote:

Im Geo-Bereich sind Shapefiles ein de-facto Standard, weil sie sehr einfach aufgebaut sind und von praktisch jeder Anwendung unterstützt werden.

Klar, wenn du damit leben kannst: https://de.wikipedia.org/wiki/Shapefile … .A4nkungen

Notepad ist übrigens auch ein netter Editor.

Gruss
walter

rurseekatze wrote:

Im Geo-Bereich sind Shapefiles ein de-facto Standard, weil sie sehr einfach aufgebaut sind und von praktisch jeder Anwendung unterstützt werden.

Shapefiles kannst du weder mit 'nem Texteditor lesen, noch ist das Format 100% offen (ähnlich wie bei PDFs). Der Todbringer bei Shapefiles war bei mir schon häufiger die Beschränkung auf 2 GB. Auch ist das Trennen von Geometrien nach ihrem Typ nicht das Gelbe vom Ei. GeoJSON hat dies eliminiert, auch wenn NOCH ein passendes Index-Format fehlt.

wambacher wrote:

https://de.wikipedia.org/wiki/Shapefile … .A4nkungen

Wait what? Wieso ist das Speichern von Fließkommazahlen als Text denn schlecht? Ich speichere eine Fließkommazahl doch lieber mit 255 Stellen in einem Textfeld ab, statt bereits nach der 8. Stelle (oder so) einen Rundungsfehler zu haben...

JPEG und andere Formate speichern Fließkommazahlen - sowie wie möglich - übrigens in Brüchen ab. Sinnvoll 🙂

TobWen wrote:

wambacher wrote:

https://de.wikipedia.org/wiki/Shapefile … .A4nkungen

Wait what? Wieso ist das Speichern von Fließkommazahlen als Text denn schlecht? Ich speichere eine Fließkommazahl doch lieber mit 255 Stellen in einem Textfeld ab, statt bereits nach der 8. Stelle (oder so) einen Rundungsfehler zu haben...

Da hast du dir gerade den einen von sieben erwähnten Schwachpunkten herausgepickt, mit dem du wohl klarkommst. Und was ist mit den anderen sechs Punkten?

Nun denn, es wird ja niemandem "verboten" weiterhin mit Shapes zu arbeiten. Und genau so wenig solltest du es anderen "vermiesen", modernere und zudem offenere Datenformate zu verwenden.

gruss
walter

ps: Ende vom Gelände - sonst wirft mir wieder wer trolliges Verhalten vor ;(