<a
<h1>Introduction</h1>
<a is an open standard data format based on <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 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 Shapefile</a> and <a href="

The following chart will quickly summarize the main differences between them.<br><br>
<table cellspacing="4" cellpadding="8" bgcolor="#c0eec0" border="1">

<tr>
<th valign="middle">File organization</th>
<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 open
<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 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 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>
<th>Geometry classes</th>
<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
<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 and limited.</li>
<li>GML is elegant and very sophisticated: sometimes too much sophisticated and complex to be really usable.</li>
<li>GeoJSON matches very well Spatial SQL requirements, and is so simple to avoid any unnecessary complexity.</li>
</ul>
</td>
</tr>
<tr>
<th>Dimensions</th>
<td>
<ul>
<li>XY</li>
<li>XYM</li>
<li>XYZ</li>
<li>XYZM</li>
</ul>
</td>
<td>
<ul>
<li>XY</li>
<li>XYM</li>
<li>XYZ</li>
<li>XYZM</li>
</ul>
</td>
<td>
<ul>
<li>XY</li>
<li>XYZ</li>
</ul>
<br>
<u>Note</u>: RFC 7946 just supports 2 or 3 coordinates, and the third value (when declared) is always expected to correspond to an Elevation (Z axis).<br><br>
Supporting XYM or XYZM is not technically unfeasible.
Both writers and readers could support such options, but all this is surely outside the standard and will surely impair the universal portability of any non canonical file.
</td>
<td>
GeoJSON lacks the capability to support XYM and XYZM, if not by adopting vicious tricks.<br>
May well be it's not a forbidding limitation in many common cases, but it's indisputably a limitation.
</td>
</tr>
<tr>
<th>SRID</th>
<td>
Not internally declared by the Shapefile itself.<br>
Deploying a further <b>.prj</b> file describing the intended SRID is the usual solution adopted by ESRI itself, but correctly parsing these extra files is an usually flimsy process falling outside real capabilities of many third party readers.
</td>
<td>
Each single Geometry is allowed to freely define its own SRID; and is also possible to define the SRID for a whole layer.
</td>
<td>
Accordingly to RFC 7946 all coordinates are always expeted to be expressed as <b>longitues</b> and <b>latitudes</b> (in this exact order).<br>
So any canonical GeoJSON file is always expected to reference <b>SRID=4326 WGS 84</b>.<br><br>
Using any other SRID is technically possible, but requires a conventional agreement between writers and readers, but all this is surely outside the standard and will surely impair the universal portability of any non canonical file.
</td>
<td>
The unique effective solution is the one adopted by GML.<br>
Both Shapefile and GeoJSON are clearly inferior under this peculiar aspect.
</td>
</tr>
<tr>
<th>Non-spatial attributes</th>
<td>
<ul>
<li>CHAR (limited to max. 254 bytes)</li>
<li>NUMBER (represented by an ASCII string of max. 32 bytes)</li>
<li>DATE (YYYYMMDD)</li>
<li>LOGICAL
</ul>
<br>
<u>Note</u>: all attribute names are limited to a length of max. 10 bytes. There is no safe way for declaring <b>NULL</b> values.
</td>
<td>
Any possible datatype you can imagine.<br>
And defining further derived datatypes is an option supported by XML Schema.<br><br>
<u>Note</u>: attribute names and text values can have any arbitrary unconstrained length.
</td>
<td>
<ul>
<li>text (unconstrained length)</li>
<li>number</li>
<li>null</li>
<li>true</li>
<li>false</li>
</ul>
<br>
<u>Note</u>: attribute names  can have any arbitrary unconstrained length.
</td>
<td>
<ul>
<li>Shapefile (or more precisely in this case DBF) clearly suffers from too many unpleasant limitations.</li>
<li>GML (more precisely XML) can effectively support an impressive flexibility but can easily become too much complex and heavy to be parsed.</li>
<li>GeoJSON offers a well balanced mix; it's still reasonably simple and it's powerful at the same time.</li>
</ul>
</td>
</tr>
<tr>
<th>Charset encoding</th>
<td>
Not internally defined by the Shapefile itself.<br>
Attempting to guess the appropriate charset encoding required by some Shapefile is more a magic art than rational science.
</td>
<td>
Always internally defined by the GML/XML file itself.
</td>
<td>
RFC 7946 strictly requires that all GeoJSON files must be encoded as <b>UTF-8</b><br><br>
In pure theory both <b>UTF-16</b> and <b>UTF-32</b> could be used for encoding a legitimate GeoJSON file, but such options seems to be very rarely (if never) adopted in real world.
</td>
<td>
<ul>
<li>Shapefiles leaves a lot to be desired, and not rarely misunderstunding the appropriate charset encoding causes many serious portability issues.</li>
<li>GML/XML nicely supports any possible charset in the most flexible (and safe)
way</li>
<li>Once again, GeoJSON is straightforward simple but really effective</li>
</ul>
</td>
</tr>
</table>
<h2>Skeletal GeoJSON anathomy</h2>
<verbatim>
{
   "type": "FeatureCollection",
   "features":
   [{
       "type": "Feature",
       "geometry":
       {
           "type": "Point",
           "coordinates": [102.0, 0.5]
       },
       "properties":
       {
           "prop0": "value0"
       }
    },
    {
       "type": "Feature",
       "geometry":
       {
           "type": "LineString",
           "coordinates":
          [
               [102.0, 0.0],
               [103.0, 1.0],
               [104.0, 0.0],
               [105.0, 1.0]
           ]
       },
       "properties":
       {
           "prop0": "value0",
           "prop1": 0.0
       }
    },
    {
       "type": "Feature",
       "geometry":
       {
           "type": "Polygon",
           "coordinates":
           [
               [
                   [100.0, 0.0],
                   [101.0, 0.0],
                   [101.0, 1.0],
                   [100.0, 1.0],
                   [100.0, 0.0]
               ]
           ]
       },
       "properties":
       {
           "prop0": "value0",
           "prop1": {"this": "that"}
       }
   }]
}
</verbatim>
As you can easily notice, GeoJSON has a plain regular structure and is decisely most concise and less verbose than GML/XML:
<ul>
<li>Every GeoJSON file must contain a <b>FeatureCollection</b> object.
<ul>
<li>A  <b>FeatureCollection</b> contains one or more individual <b>Feature</b> objects.
<ul>
<li>Each <b>Feature</b> is expected to declare a <b>Geometry</b> and a <b>properties</b> array.
<ul>
<li>Each property coresponds to an attribute with a <b>name</b> and a


</ul>
<h3>Short conclusions</h3>
GeoJSON is widely adopted by many web-apps; being a notation directly based on <b>JavaScript</b> it has a natural integration in popular <i>client-side</i> JS libraries such as <a and <a
It's adequately supported by <a and consequently by many others free/libre sw components (as e.g. <a and <a
Outside the web-gis arena GeoJSON still has limited adoption, and it's a real pity because under many aspects it's a very valid full replacement for the nowadays irremediably obsolete Shapefile.<br>
Starting since version <b>5.0.0</b> SpatiaLite offers full supports to GeoJSON as defined by RFC 7946.<br>
The implementation strongly resembles the one supported by all previous versions for Shapefile, and this isn't at all surprising because both them cover the same functional area.
<br><br>
<hr><br>
<a