spatialite-tools: Update of "OSM tools"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview

Artifact ID:	8eeaaf2f8c40594bc40a7aa9c68e0da7597268cd
Page Name:	OSM tools
Date:	2012-05-02 17:35:59
Original User:	sandro
Next	2d8b3b5b472d9acca3880c762c9b1ecf2028675d

Content

Few basic notices you must absolutely know about OSM datasets

Open Street Map (OSM) is a community-driven project aimed to produce a high-quality detailed map of the world.
OSM datasets are freely available under the CC-BY-SA license terms: two popular download sites are Geofabrik and CloudMade

OSM adopts a quasi-topological data model: map object are represented accordingly to the following object hierarchy:

Node: an OSM-Node simply corresponds to a POINT Geometry; the geographic coordinates are always expressed as Longitude and Latitude (thus corresponding to SRID 4326).
Way: an OSM-Way corresponds to a LINESTRING Geometry: all points representing the line are represented by indirectly referenced Nodes.
Relation: an OSM-Relation is a complex object. It can correspond to a POLYGON, to a MULTILINESTRING, or even to a GEOMETRYCOLLECTION.
An OSM-Relation object can indirectly reference any other kind of OSM objects: Nodes, Ways or other Relations.

All OSM map objects can be eventually qualified by a rich set of data attributes:

id: a number uniquely identifying each OSM map object.
version: a progressive number identifying subsequent versions of the same object.
changeset: a progressive number identifying a changeset, i.e. a batch insert/update performed by same user.
user: nickname of the user (aka mapper in OSM parlance) committing the changeset.
uid: a number uniquely identifying the user.
timestemp: commit date-time
Any further arbitrary data attribute could be freely specified using a tag list, i.e. including a dictionary based on key:value pairs.
A standard tag specification 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.

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:

<node id="1001" lat="6.6" lon="7.7" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z">
    <tag key="created_by" value="JOSM" />
    <tag key="tourism" value="camp_site" />
</node>
<way id="5000" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z">
    <nd ref="1001" />
    <nd ref="1002" />
    <nd ref="1003" />
    <tag key="created_by" value="JOSM" />
    <tag key="tourism" value="camp_site" />
</way>
<relation id="9000" version="1" changeset="2" user="eta" uid="6" timestamp="2005-02-28T17:45:15Z">
    <member type="way" ref="5000" role="outer" />
    <member type="way" ref="5001" role="inner" />
    <tag key="created_by" value="JOSM" />
    <tag key="tourism" value="camp_site" />
</relation>

Usually OSM datasets can be downloaded in two different formats:

OSM files identified by the .osm suffix are XML files: they are often shipped as highly compressed files, and in this case they are identified by the .osm.bz2 suffix.
The alternative OSM-protobuf format is identified by the .pbf or .osm.pbf suffix.
This format is much more compact than XML (smaller size), and no preliminary decompression is required.
All SpatiaLite tools supporting OSM can indifferenctly parse both formats indifferenctly (thanks to readosm support).

spatialite_osm_map

This tool is intended to parse a whole OSM dataset, thus creating the corresponding SpatiaLite's DB-file.
Geometries are reassembled in the canonical form of POINTs, LINESTRINGs and POLYGONs.
Maps objects are then aggregated by distinct omogeneous layers (aka tables in DBMS parlance) accordingly to declared tags.
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. QGIS).

spatialite_osm_raw

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.
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.
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.

spatialite_osm_filter

This tool works the opposite way: a DB-file (one previously created by spatialite_osm_raw) will be processed so to create an OSM-XML file.
A mask (i.e. an arbitrary polygonal shape) will be used in order to spatially filter 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.
The intended goal of this tool is the one to produce selected datasets, to be further processed.

spatialite_osm_net

Yet again this tool will parse a whole OSM dataset, thus creating a corresponding SpatiaLite's DB-file.
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.
The intended goal of this tool is the one to produce a valid graph to be used in a later step in order to support the SpatiaLite's own Routing module (VirtualNetwork).