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- _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
