Handling of "Multi" geometries in flex output

[joto]

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 ?

[mboeringa]

@joto

A lot of sense in what you write, and I agree with most of it.

Just one remark about the potential splitting of Polygons: it would be most logical to use ST_Subdivide for this. Do note that this is a far more expensive operation than simply splitting LineStrings. Also note that splitting polygons comes with a couple of caveats:

• Any internal rings / holes that are being cut by the subdivision lines can no longer be removed during any subsequent generalization step, as they are no longer inner holes.
• Any smoothing step applied after the splitting, e.g. using ST_ChaikinSmoothing will cause (small) gaps at the crossing of subdivision lines, as the corners will collapse inwards.
• Subdivision lines can be very long and cause issues when attempting to reproject data or using on-the-fly reprojection. Adding in a configurable densification step using e.g. ST_Segmentize may be desirable in some cases.

Probably all a bit out of scope here, but it may be good to keep this in mind anyway.

[joto]

This has been implemented and documented now. Closing here.