<h3>Few basic notices you must absolutely know about OSM datasets</h3>
<a Street Map</a> (<b>OSM</b>) is a community-driven project aimed to produce a high-quality detailed map of the world.<br>
OSM datasets are freely available under the <a license terms: two popular download sites are <a and <a
OSM adopts a <i>quasi-topological</i> data model: map object are represented accordingly to the following object hierarchy:<ul>
<li><b>Node</b>: an OSM-Node simply corresponds to a POINT Geometry; the geographic coordinates are always expressed as Longitude and Latitude (thus corresponding to SRID 4326).</li>
<li><b>Way</b>: an OSM-Way corresponds to a LINESTRING Geometry: all points representing the line are represented by indirectly referenced Nodes.</li>
<li><b>Relation</b>: an OSM-Relation is a complex object.
It can correspond to a POLYGON, to a MULTILINESTRING, or even to a  GEOMETRYCOLLECTION.<br>
An OSM-Relation object can indirectly reference any other kind of OSM objects: Nodes, Ways or other Relations.</li>
</ul><br>
All OSM map objects can be eventually qualified by a rich set of data attributes:<ul>
<li><b>id</b>: a number uniquely identifying each OSM map object.</li>
<li><b>version</b>: a progressive number identifying subsequent versions of the same object.</li>
<li><b>changeset</b>: a progressive number identifying a <i>changeset</i>, i.e. a batch insert/update performed by same user.</li>
<li><b>user</b>: nickname of the user (aka <i>mapper</i> in OSM parlance) committing the changeset.</li>
<li><b>uid</b>: a number uniquely identifying the user.</li>
<li><b>timestemp</b>: commit date-time</li>
<li>Any further arbitrary data attribute could be freely specified using a <b>tag list</b>, i.e. including a based on pairs.<br>
A standard <a specification</a> exists, but anyway this one is by definition a variable list: each single mapper can freely add further tags accordingly to his/her personal taste.</li>
</ul><br>
Usually OSM datasets are released as XML file: so the following XML snippet will probably help you to better understand the general OSM data model:
<table border="1"><tr><td><pre>
&lt;node id="1001" lat="6.6" lon="7.7" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z"&gt;
    &lt;tag key="created_by" value="JOSM" /&gt;
    &lt;tag key="tourism" value="camp_site" /&gt;
&lt;/node&gt;
&lt;way id="5000" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z"&gt;
    &lt;nd ref="1001" /&gt;
    &lt;nd ref="1002" /&gt;
    &lt;nd ref="1003" /&gt;
    &lt;tag key="created_by" value="JOSM" /&gt;
    &lt;tag key="tourism" value="camp_site" /&gt;
&lt;/way>
&lt;relation id="9000" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z"&gt;
    &lt;member type="way" ref="5000" role="outer" /&gt;
    &lt;member type="way" ref="5001" role="inner" /&gt;
    &lt;tag key="created_by" value="JOSM" /&gt;
    &lt;tag key="tourism" value="camp_site" /&gt;
&lt;/relation&gt;

Usually OSM datasets can be downloaded in two different formats:<ul>
<li>OSM files identified by the suffix are XML files: they are often shipped as highly compressed files, and in this case they are identified by the suffix.</li>
<li>The alternative OSM-protobuf format is identified by the or suffix.<br>
This format is much more compact than XML (smaller size), and no preliminary decompression is required.</li>
<li>All SpatiaLite tools supporting OSM can indifferenctly parse both formats indifferenctly (thanks to support).</li>
</ul>
<h3>spatialite_osm_map</h3>
This tool is intended to parse a whole OSM dataset, thus creating the corresponding SpatiaLite's DB-file.<br>
Geometries are reassembled in the canonical form of POINTs, LINESTRINGs and POLYGONs.<br>
Maps objects are then aggregated by distinct omogeneous (aka in DBMS parlance) accordingly to declared
The intended goal of this tool is the one to produce a DB-file suited to be immediately used with some appropriate GIS application (e.g. <b>QGIS</b>).<br>
Want to learn more ? read a practical <a
<h3>spatialite_osm_raw</h3>
Also this tool is intended to parse a whole OSM dataset, thus creating the corresponding SpatiaLite's DB-file; but in this case the generated DB-file will adopt a completely different data layout than in the previous scenario.<br>
In this case will be adopted a data layout closely mapping OSM objects, their data attributes and their mutual relationships; fully preserving the original OSM data model, and carefully avoiding to introduce any unpleasant information suppression.<br>
The intended goal of this tool is not at all to produce a DB-file usable by GIS applications: it's instead the one to get a DB-file you can use in order to gather statistical infos, to support some post-processing task and so on.<br>
Want to learn more ? read a practical <a
<h3>spatialite_osm_filter</h3>
This tool works the opposite way: a DB-file (one previously created by will be processed so to create an OSM-XML file.<br>
A (i.e. an arbitrary polygonal shape) will be used in order to <i><u>spatially the map objects to be inserted into the output file. Any map object fully or partially overlapping the given mask will be exported; any other object will be silently ignored.<br>
The intended goal of this tool is the one to produce selected datasets, to be further processed.<br>
Want to learn more ? read a practical <a
<h3>spatialite_osm_net</h3>
Yet again this tool will parse a whole OSM dataset, thus creating a corresponding SpatiaLite's DB-file.<br>
In this specific case any possible effort will be done in order to extract from the OSM dataset a valid Road (or Railway) Network represented by Nodes and Arcs.<br>
The intended goal of this tool is the one to produce a valid to be used in a later step in order to support the SpatiaLite's own Routing module
Want to learn more ? read a practical <a and get more detailed infos about <a Networks and graphs</a>