[gdal-dev] Basic OpenStreetMap driver with ReadOSM?
even.rouault at mines-paris.org
Sat Jul 7 03:01:10 PDT 2012
Le samedi 07 juillet 2012 11:07:35, Jukka Rahkonen a écrit :
> 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
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
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,
> -Jukka Rahkonen-
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev