[gdal-dev] OSM driver to create separate tables for tags

[Jukka Rahkonen]

Andre Joost <andre+joost <at> nurfuerspam.de> writes:

> 
> Am 14.05.2014 16:41, schrieb Jukka Rahkonen:
> 
> > I wonder if it would make any sense in the GDAL context to have an option in
> > the OSM driver to separate geometries and tags and write them into their own
> > tables. The structure of the resulting tables (5 + 5 for points, lines,
> > multilines, multipolygons and relations) would be like:
> 
> Why would you distinguish between line and multiline? The database 
> schema for rendering does not do it, and the OSM data model does it not too.

Read the driver manual http://www.gdal.org/ogr/drv_osm.html
Multilinestrings are mostly route relations. Line members of these relations
go also into line layer.

> What is still missing is any kind of support for the 'role' field in 
> relations. This is set for every member separately, not the whole 
> relation as tags do.
> For public transport relations, the role specifies if a way is part of 
> the route, or a platform. Power relations work similar (line or 
> substation), and turn restrictions as well as destination signs make no 
> sense without them (from - via - to).
> 
> Apart from that, your scheme looks good. Not sure about performance 
> issues, if you have huge datasets.

Complicated relations are very hard to turn into simple feature model. GDAL
is doing its best by saving them into GeometryCollections with the relation
tags but handling turn restrictions and so on must be done with special
programs. I consider that GDAL is doing mostly the same than osm2pgsql, but
it has more output formats and it is more flexible. Comprehensive SQL
support with SQLite dialect is wonderful.

I do not see any reason why it should be much if any slower with separated
tables than now when write tags are written into fixed schmema and to
additional all_tags column, which should stay as the default. And for
moderately sized datasets, like finland.osm.pbf or germany.osm.pbf GDAL is
faster than osm2pgsql, especially on weak computers.

-Jukka Rahkonen-