D 2019-01-21T10:16:57.721 L Supporting\sGeoJSON U sandro W 5517 back

Introduction

GeoJSON is an open standard data format based on JSON (JavaScript Object Notation), a very popular data format widely adopted by many web-apps as a replacement for XML.
The specific scope of GeoJSON is extending the basic capabilities of JSON so to adequately support geographic features including both Geometries and non-spatial attributes.

GeoJSON exists since many years being based on a loose and informal data specification.
Only very recently (2016) it has finally become a respectable standard format based on a formal specification, that is RFC 7946 released by IETF (Internet Engineering Task Force).
Note: RFC 7946 introduced several relevant requirements and restrictions, so that pre-RFC and post-RFC GeoJSON files are not mutually interoperable.

A very remarkable feature of RFC 7946 is that it's explicitly declared to be a fixed and immutable specification.
There will never be updated versions of GeoJSON; even the slighter change will inexorably require changing the name from GeoJSON to some else.
Such a restrinction is obviosly intended to ensure a very strong stability during the time.

The most obvious competitors of GeoJSON are the ESRI Shapefile and GML
The following chart will quickly resume the main differences between them.

Category	Shapefile	GML	GeoJSON	Remarks
File organization	At least three independent files sharing the same name and respectively identified by suffixes .shp, .shx and .dbf Both the .shp and .shx members are binary files intended to store Geometries and should be encoded accordingly to ESRI open specification The .dbf member is intended to store non-spatial attributes. This too is a binary file expected to be encoded accordingly to Ashton-Tate dBase specification; unhappily this very old specification (born in the '80s) had a savage proliferation of different dialects (Clipper, FoxPro) becoming quite messy and chaotic.	GML is based on XML, and conseguently just requires a single, monolithic text file. As any other XML file, GML too can be strongly constrained to verbatim respect a formally defined XML Schema	Single monolithic text file. Similar in this to XML, but explicitly intended to be by way simpler and less verbose.	The three-files layout of Shapefile is clearly obsolete, and it frequently poses many headaches causing unexpected troubles. The single-file layout adopted by both GML and GeoJSON is clearly better and safer, and being text files they can be easily inspected and eventually debugged just using any generic text editor without requiring any specific tool.
Supported Geometry classes	Null Shape Point MultiPoint PolyLine (without distinguishing between single- and multi-part) Polygon (without distinguishing between single- and multi-part) Notes: All Geometries in the same Shapefile must share the same class (or be Null). All Geometries in the same Shapefile must share the same SRID. The rules for identifying Exterior and Interior Polygon rings are awkward and can frequently cause interoperability issues.	GML allows many different ways for defining the same Geometry, and the specifications radically changed from version to version. GML has a really impressive flexibily (e.g. each single Geometry can freely declare its own SRID), but at the cost of imposing an overwhelming complexity.	Null Point Linestring Polygon MultiPoint MultiLinestring MultiPolygon GeometryCollection Notes: This exactly corresponds to the standard 7 classes model adopted by Spatial SQL. The same GeoJSON file can freely contain any kind of Geometry classes withour restrictions. All Geometries in the same GeoJSON file must share the same SRID.	Shapefile is obviously obsolete, and someway messy. GML is elegant and very sophisticated: sometimes too much sophisticated to be really usable. GeoJSON matches very well Spatial SQL requirements, and is reasonably simple avoiding any unnecessary complexity.