[Tile-serving] [openstreetmap/osm2pgsql] Handling of "Multi" geometries in flex output (#1316)

[Jochen Topf]

The flex output is still experimental. This gives us the chance to re-think the non-multi vs. multi-geometry issues. I see two distinct issues here:

1. Should multi-geometries be split into single geometries?
2. How does the generation of geometries relate to the type of the target geometry column?

Lets look at (multi)polygons first.

ad 1)

* Pro splitting: Faster index lookup, faster rendering, its what osm2pgsql has been doing as default up to now
* Con splitting: Ids not unique any more, rendering problems with labels, not expected by new users

ad 2) Closed ways and some multipolygon relations will result in Polygon geometries, other multipolygon relations in MultiPolygon geometries. If the target column has type "Geometry" we can store both Polygons and Multipolygons in it. If the target column has type "MultiPolygon" and we want to store a Polygon in it, we can either error out or "upgrade" all Polygons to MultiPolygons. If the target column has type "Polygon" and we want to store a "Multipolygon" we can either error out split it into several rows.

My current thinking here is:

ad 1) The default should be not to split. It is the "safe" choice, the one with the least surprises. Splitting is a performance tweak that has its drawbacks, so people should have to conciously choose it. This is also easier to document/explain.
ad 2) Setting a column type is a concious choice by the user. So if they choose, "Geometry", "Polygon", or "MultiPolygon" type, this is what they should get. But splitting of MultiPolygons in rows (see 1) should not be done automatically if the column has type row, instead this should be the one option, people have to set.

See also:

* http://www.paulnorman.ca/blog/2014/03/osm2pgsql-multipolygons/
* #1313 

Now to LineStrings: Here the situation is somewhat different. We are not splitting MultiLinestrings, we are splitting long lines. The flex output already doesn't do this any more unless the `split_at` parameter is used. This allows the user to set the maximum length of the segments and has the obvious default of "do not split". We could introduce a special value for `split_at` that says: Only split MultiLineStrings into their members, if we want that. But otherwise this looks okay to me.

For the column type issue (2) I think this should have the same logic as for (Multi)Polygons.

And now that I am thinking about all this: Maybe the behaviour for LineStrings and Polygons should be more similar? What if the splits of Multipolygons can do the equivalent of the LineString split and split a (Multi)Polygon along a grid? We don't have to introduce this now, but it would be the logical extension of what we have now.

@pnorman ? @lonvia ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/1316
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20201110/ddac5004/attachment.htm>