How to filter (postgis) Multipolygon in LUA

[tordans]

Some context:

We are doing some work of our processing in LUA and some in SQL.
We are only interested in areas data for this specific part of the code. But since OSM has this setup where areas with a hole are relations, we have to ways and relations.
With relations, we now get multiple data types

• relations which are in fact a Multipolygon (separate areas)
• relations which are a Polygon with a hole

We want to process the Polygons and insert them in a table with geometry type Polygon.
And as such skip the Multipolygon areas.

(The data we are working with are small areas (parking spaces), not large relations, so osm2pgsqls auto-splitting (ref) is no concern here.)

What is the best way to do this?

• We cannot use object.type because that is just relation https://osm2pgsql.org/doc/manual-v1.html#processing-callbacks
• We call object:as_multipoint() and hope it returns nil if that is not possible, because it explodes.
• We could start try-catching in LUA but that does not feel right https://www.lua.org/pil/8.4.html

Our current approach:

Code: https://github.com/FixMyBerlin/tilda-geo/blob/develop/processing/topics/parking/separate_parkings/parking_separate_parking_areas.lua

1. We set our table definition to type = 'polygon'
2. We then get our geometry with geom = object:as_multipolygon()
3. We then check if geom:num_geometries() == 1 and only then insert the data
4. (We log the other case for debugging and cleanup)

I this the way you would solve this?

A different approach might be to check the .members and their role and see if more than one outer ring is present. (https://osm2pgsql.org/doc/manual-v1.html#single-vs-multi-geometries) But we did not try that since the above seemed more straight forward.

Update the docs?

If this is the recommended approach, would this be something for the docs?
Eg in https://osm2pgsql.org/doc/manual-v1.html#single-vs-multi-geometries we could add a paragraph like…

The best way to detect if a relation will likely be transformed into a Polygon or MultiPolygon is by checking num_geometries. object:as_multipolygon():num_geometries() == 1 are Polygons, > 1 are MultiPolygons.

[joto]

I don't understand why you just ignore multipolygons with more than one polygon in it. You'll loose data that way. It seems to me it would be much simpler to iterate over all polygons in the multipolygon and insert each one on its own (example). That way you have all the data and don't need to mess around with multipolygons in the database.

If you really want to ignore multipolygons with more than one polygon in it, the num_geometries() == 1 is the correct way of doing this. Any other check (with members and roles and so on) will not work for all cases.

[tordans]

I don't understand why you just ignore multipolygons with more than one polygon in it. You'll loose data that way.

Yes, but the data is bad anyways because relations on parking areas tend to be broken in the sense that the tagging rarely make sense.

It seems to me it would be much simpler to iterate over all polygons in the multipolygon and insert each one on its own (example). That way you have all the data and don't need to mess around with multipolygons in the database.

Ah, that is good to know. But I would also have to handle the tags on the relation vs. the members, which I don't have a setup for for performance reasons for now… and even then, the tags are hard to merge due to tagging conflicts between the sets of tags :-/

Maybe something like osm2pgsql-dev/osm2pgsql-website#72 can give this more visibility. I can copy that to the V2 docs should that be mergable…