D 2019-01-21T10:16:57.721
L Supporting\sGeoJSON
U sandro
W 5517
<a href="https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.3.0-doc">back</a><hr><br>
<h1>Introduction</h1>
<a href="https://en.wikipedia.org/wiki/GeoJSON">GeoJSON</a> is an open standard data format based on <a href="https://en.wikipedia.org/wiki/JSON">JSON</a> (<b>JavaScript Object Notation</b>), a very popular data format widely adopted by many web-apps as a replacement for XML.<br>
The specific scope of GeoJSON is extending the basic capabilities of JSON so to adequately support <b>geographic features</b> including both <b>Geometries</b> and
<b>non-spatial attributes</b>.<br><br>
GeoJSON exists since many years being based on a loose and informal data specification.<br>
Only very recently (2016) it has finally become a respectable standard format based on a formal specification, that is <a href="https://tools.ietf.org/html/rfc7946">RFC 7946</a> released by <b>IETF</b> (<i>Internet Engineering Task Force</i>).<br>
<u>Note</u>: RFC 7946 introduced several relevant requirements and restrictions, so that <b>pre-RFC</b> and <b>post-RFC</b> GeoJSON files are not mutually interoperable.<br><br>
A very remarkable feature of RFC 7946 is that it's explicitly declared to be a <b>fixed and immutable</b> specification.<br>
There will never be updated versions of GeoJSON; even the slighter change will inexorably require changing the name from GeoJSON to some else.<br>
Such a restrinction is obviosly intended to ensure a very strong stability during the time.<br><br>
The most obvious competitors of GeoJSON are the <a href="https://en.wikipedia.org/wiki/Shapefile">ESRI Shapefile</a> and <a href="
https://en.wikipedia.org/wiki/Geography_Markup_Language">GML</a><br>
The following chart will quickly resume the main differences between them.<br><br>
<table cellspacing="4" cellpadding="8" bgcolor="#c0eec0" border="1">
<tr><th>Category</th><th>Shapefile</th><th>GML</th><th>GeoJSON</th><th>Remarks</th></tr>
<tr>
<td valign="middle">File organization</td>
<td valign="middle">At least three independent files sharing the same name and respectively identified by suffixes <b>.shp</b>, <b>.shx</b> and <b>.dbf</b>
<ul>
<li>Both the <b>.shp</b> and <b>.shx</b> members are <b>binary files</b> intended to store Geometries and should be encoded accordingly to <a href="https://www.esri.com/library/whitepapers/pdfs/shapefile.pdf">ESRI open specification</a></li>
<li>The <b>.dbf</b> member is intended to store non-spatial attributes.<br>
This too is a <b>binary file</b> expected to be encoded accordingly to <a href="https://en.wikipedia.org/wiki/DBase">Ashton-Tate dBase specification</a>; unhappily this very old specification (born in the '80s) had a savage proliferation of different dialects (<i>Clipper</i>, <i>FoxPro</i>) becoming quite messy and chaotic.</li>
</ul>
</td>
<td>GML is based on XML, and conseguently just requires a single, monolithic <b>text file.</b><br>
As any other XML file, GML too can be strongly constrained to verbatim respect a formally defined <a href="https://it.wikipedia.org/wiki/XML_Schema">XML Schema</a>
</td>
<td valign="middle">
Single monolithic <b>text file</b>.<br>
Similar in this to XML, but explicitly intended to be by way simpler and less verbose.
</td>
<td>
The three-files layout of Shapefile is clearly obsolete, and it frequently poses many headaches causing unexpected troubles.<br><br>
The single-file layout adopted by both GML and GeoJSON is clearly better and safer, and being <b>text files</b> they can be easily inspected and eventually debugged just using any generic <b>text editor</b> without requiring any specific tool.
</td>
</tr>
<tr>
<td>Supported Geometry classes</td>
<td>
<ul>
<li>Null Shape</li>
<li>Point</li>
<li>MultiPoint</li>
<li>PolyLine (without distinguishing between single- and multi-part)</li>
<li>Polygon (without distinguishing between single- and multi-part)</li>
</ul>
<br>
<u>Notes</u>:
<ul>
<li>All Geometries in the same Shapefile must share the same class (or be <b>Null</b>).</li>
<li>All Geometries in the same Shapefile must share the same SRID.</li>
<li>The rules for identifying <b>Exterior</b> and <b>Interior</b> Polygon rings
are awkward and can frequently cause interoperability issues.</li>
</ul>
</td>
<td>
GML allows many different ways for defining the same Geometry, and the specifications radically changed from version to version.<br><br>
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.
</td>
<td>
<ul>
<li>Null</li>
<li>Point</li>
<li>Linestring</li>
<li>Polygon</li>
<li>MultiPoint</li>
<li>MultiLinestring</li>
<li>MultiPolygon</li>
<li>GeometryCollection</li>
</ul>
<br>
<u>Notes</u>:
<ul>
<li>This exactly corresponds to the standard <b>7 classes</b> model adopted by Spatial SQL.</li>
<li>The same GeoJSON file can freely contain any kind of Geometry classes withour restrictions.</li>
<li>All Geometries in the same GeoJSON file must share the same SRID.</li>
</ul>
</td>
<td>
<ul>
<li>Shapefile is obviously obsolete, and someway messy.</li>
<li>GML is elegant and very sophisticated: sometimes too much sophisticated to be really usable.</li>
<li>GeoJSON matches very well Spatial SQL requirements, and is reasonably simple avoiding any unnecessary complexity.</li>
</ul>
</td>
</tr>
</table>
<hr><br>
<a href="https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.3.0-doc">back</a>
Z 47f844359ea0fb93d6fd4ab6443feb31