[gdal-dev] Basic OpenStreetMap driver with ReadOSM?

[Even Rouault]

Le samedi 07 juillet 2012 11:07:35, Jukka Rahkonen a écrit :
> Hi,
> 
> I was wondering if the ReadOSM library
> (https://www.gaia-gis.it/fossil/readosm/index) by Alessandro Furieri could
> be utilised for making a basic read-only OpenStreetMap driver. Basic
> driver would read OSM data in XML or pbf format and write out point, line
> and polygon layers with a fixed attribute schema following a tag list
> which user could give as input. ReadOSM seems to have most if not all that
> is needed for that. A ready made spatialite_osm_map program is some
> example into that way but it is not made for generic use. It imports a
> hardcoded set of tags and creates a predefined set of layers
> https://www.gaia-gis.it/fossil/spatialite-tools/index.

Jukka,

I've a PBF parser and an embryonic OGR OSM driver in a local tree (I realize 
that it is sitting there for years in fact!), but it didn't yet make its way 
through svn, because I wasn't yet sure how to deal with a few key points that 
must be solved, to avoid doing just a "toy" driver :

- what kind of output would be the most usefull ?
     * Raw OSM data (but that doesn't fit really with the SimpleFeature model 
of OGR. That would be more suited for a topology engine),
     * or something more elaborated where linestrings and polygons and 
multipolygons geometry are built by examining ways and relations objects ? In 
that case, would the driver report in a 'osm_point' layer the nodes that have 
no associated tags (key/value pairs) ?

- For building the geometries, you need to access the nodes and/or ways that 
have been read before. The simple solution is to store them in RAM, but at 
some point, if the .osm file is too big, that will not work. Otherwise you need 
to write them into a temporary file/DB. That doesn't really follow the general 
philosophy of OGR drivers, except that recently we have done similar things in 
the GML driver or the VFK driver, by using a temporary SQLite DB, so that 
might be a possibility for a OGR OSM driver.

- The topology model of OSM data is rather loosely defined. For example, how do 
you know if a way is a linestring or a polygon ? Quoting 
http://wiki.openstreetmap.org/wiki/Elements#Area :
"""
An Area (also polygon) is an enclosed filled area of territory defined as a 
closed Way. Closed ways with some tags such as landuse=* are assumed to be 
areas, others, such as highway=footway are assumed to be closed Polylines 
unless they also have a area=yes tag. 
"""

Reading that I'm wondering if the presence of the landuse tag is the only case 
where area=yes is implicit, or if there are not other similar cases ? So, 
should we hardcode that rule, or make something more configurable, with a 
syntax has to be determined.

- You are also mentionning the possibility of having custom layers. My idea up 
to now was just to have layers like "osm_points", "osm_lines", "osm_polygons", 
but having something more advanced is certainly interesting. The syntax for 
configuring the layers and attributes would have to be determined.

- Last but not least, is there really an interest for such a driver given all 
the existing advanced tools that do similar things : osm2pgsql, osmosis, 
etc... ?

> 
> -Jukka Rahkonen-
> 
> 
> 
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev