Should planet_osm_polygons have MultiPolygon geometry type, not Geometry?

[amandasaurus]

Currently, when you use osm2pgsql, the planet_osm_polygons table has a way column with type geometry(Geometry, $SRID). This means the way column could could contain any sort of geometry, points, lines, polygons, etc. This seems a little silly, surely the planet_osm_polygons table should be something polygon-ish. It would make sense for the type to be a MultiPolygon. Standard Polygons can be converted to MultiPolygons (a multipolygon with just one polygon).

This issue is firstly to ask: Does this make sense? Or should planet_osm_polygons be a Geometry type? I asked about this on #osm-dev IRC channel to broadly positive feedback (with the standard OSM reason of "No-one's done it yet" :))

My main desire for wanting change, is because I had a problem with mapnik taking a very long time to start up (>1hr) because it was trying to find the geometry type of queries in the openstreetmap-carto style which used the polygon table. As far as I could tell, this mapnik function (specifically this part) will, for non-Point/Linestring/Polygon/ columns, run each query and look at the first 5 results. Many of the osm-carto styles make use of ORDER BY clauses (e.g. the text-poly layer). You don't want to run that query without a bbox limitation on the whole planet! But this is exactly what mapnik does IME. If you change the data type of planet_osm_polygons.way to geometry(MultiPolygon, $SRID) (ALTER TABLE planet_osm_polygon ALTER COLUMN way TYPE geometry(MultiPolygon,. $SRID) USING ST_Multi(way);), then mapnik does not try to query the whole database, and will instead recognise straight away that it's a polygon-ish type, making a massive start up speed up.

If you change the column type, then everything works. Except you cannot do updates, because osm2pgsql will still spit out POLYGON which causes a data type problem in PostgreSQL.

re: -G/--multi-geometry flag. In this proposal nothing would change. With -G, you'll have one row, with one MultiPolygon with N polygons. Without -G, you'll have N rows, each a MultiPolygon with 1 polygon.

As well as asking if this is a good idea, I'm creating this issue to ask developers for help in how to implement this. I am not good at C++, and unfamiliar with osm2pgsql source code. I have started a branch, and have made the geometry type be MultiPolygon upon table creation, however my attempt to change the output geometry in geometry_builder.cpp failed.

[pnorman]

Standard Polygons can be converted to MultiPolygons (a multipolygon with just one polygon).

There are operations you can do on polygons that you can't do on multipolygons

[amandasaurus]

Standard Polygons can be converted to MultiPolygons (a multipolygon with just one polygon).

There are operations you can do on polygons that you can't do on multipolygons

I can see ST_ExteriorRing, are there others?

How about this: When using -G option, the data type could be MuliPolygon, and without -G it would be Polygon? Then the user will get data that works with the queries they expect to work.

[amandasaurus]

FYI, I have mostly gotten imports working on my branch, however I am still working on getting data updates working.

[amandasaurus]

Data updates are working. It was just a problem with using a db installed with an older osm2pgsql version.

[lonvia]

The new 'flex' output allows to chose the type of the geometry column. We still need tests that this works as expected in all cases. Still closing here. Open a new issue if you find a case that does not work for you with the 'flex' output.