GeoJSON-Standard veröffentlicht

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… Als Standard-CRS wird nun WGS84 definiert.

Ich frage mich echt, was die dazu bewegt hat, sich auf ein festes CRS einzuschießen… In der GIS-Welt gibt’s nicht viele offene und einfache Dateiformate. Okay, Alternativen her!

SQLite (Spatialite) ist nicht mal eben mit dem Texteditor verarbeitbar, OSM unterstützt (offiziell) auch nur WGS84. WKT gibt’s ja noch aber … wo will man damit hin? Mal gucken, wann TopoJSON dem Ganzen nachzieht.

Edit: Titel etwas verkürzt-

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

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

Die Begründung finde ich nicht schlecht:

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.

GML?

Grüße
Max

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

Gruss
walter

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 :frowning:

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 :slight_smile:

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

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

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

Notepad ist übrigens auch ein netter Editor.

Gruss
walter

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.

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 :slight_smile:

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 ;(