OSM: (Multi-)Polygons in other_relation get always stored as LineStrings

[tobwen]

When you load the attached (or all other) OSM files with ogr2ogr, other_relation's GeometryCollection doesn't get parsed in their correct geometry:

{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [
{ "type": "Feature", "properties": { "osm_id": "1", "name": null, "type": null, "other_tags": "\"route\"=>\"bus\"" }, "geometry": { "type": "GeometryCollection", "geometries": [ { "type": "LineString", "coordinates": [ [ 7.4592804, 51.4674372 ], [ 7.4594837, 51.4673888 ] ] }, { "type": "LineString", "coordinates": [ [ 7.4594837, 51.4673888 ], [ 7.4597202, 51.4673325 ] ] }, { "type": "LineString", "coordinates": [ [ 7.4597202, 51.4673325 ], [ 7.459888, 51.4672926 ] ] }, { "type": "LineString", "coordinates": [ [ 7.4597851, 51.4673534 ], [ 7.4598009, 51.467379 ], [ 7.4594547, 51.4674624 ], [ 7.4594388, 51.4674368 ], [ 7.4597851, 51.4673534 ] ] } ] } }
]
}

But actually, osm_id/osm_way_id=4 is a polygon. So this information is lost in other_relations:

{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [
{ "type": "Feature", "properties": { "osm_id": null, "osm_way_id": "4", "name": null, "type": null, "aeroway": null, "amenity": null, "admin_level": null, "barrier": null, "boundary": null, "building": null, "craft": null, "geological": null, "historic": null, "land_area": null, "landuse": null, "leisure": null, "man_made": null, "military": null, "natural": null, "office": null, "place": null, "shop": null, "sport": null, "tourism": null, "other_tags": "\"bus\"=>\"yes\",\"highway\"=>\"platform\",\"public_transport\"=>\"platform\"" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [ 7.4597851, 51.4673534 ], [ 7.4598009, 51.467379 ], [ 7.4594547, 51.4674624 ], [ 7.4594388, 51.4674368 ], [ 7.4597851, 51.4673534 ] ] ] ] } }
]
}

Furthermore, the ID and all tags get lost. So it's impossible to track the items in other_relations.

Maybe it would be a solution, NOT to store geometries in other_relations at all, but store the IDs only, like in a normal XML file. The user could JOIN and create his own GeometryCollection using ST_Collect() inside SQLite/Spatialite.

[Jukka Rahkonen]

I think that GDAL is doing the right thing by converting relations into GeometryCollections that is a single Simple Feature. That means by the same that tags which belong to the relation are preserved but those which belong to members are lost.

With your sample data the platform gets parsed with all the attributes into the multipolygons layer so the geometry and tags are not totally lost or hidden but it can really be difficult to connect it from there to the route that it belongs to.

There are other tools which can be used for importing the geometry primitives and IDs to be used for joins. Spatialite especially has a dedicated tool for that ​https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=spatialite_osm_raw.

It feels like a bug that geometry of platform is saved as multipolygon into multipolygons layer but as linestring into corresponding GeometryCollection on the other_relations layer.

[Even Rouault]

trunk r34094, r34095, branches/2.1 r34096 r34098 (post 2.1.0RC3), branches/2.0 r34097 r34099 "OSM: properly deal with polygons in other_relations geometrycollection (#6475)"

Regarding exposing IDs of geometry primitives, this would rather be an improvement/alternate way of doing. Should be rather put in a dedicated enhancement ticket.