[OSM-dev] osm2pgsql and only-named multipolygons

Frederik Ramm frederik at remote.org
Tue Oct 4 10:57:04 BST 2011


On 10/04/11 11:41, Andy Allan wrote:
> In osm2pgsql we handle two types of multipolygons - those with the
> "useful" tags on the relation, and those with no "useful" tags on the
> relation where we use the outer ways instead. Note that we also
> explicitly allow the relations to have a name. See
> http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c?rev=26664#L1001

I think that the handling of relations in osm2pgsql is far from perfect. 
I have the impression that relations in osm2pgsql is a collection of 
itches-that-were-scratched, and if I remember correctly then I am not 
even an innocent bystander in this ;)

> However, one relation has caused me lots of issues, namely
> http://www.openstreetmap.org/api/0.6/relation/1715069 . It's a giant
> relation with a name, type, and nothing else, and so osm2pgsql creates
> a polygon using one of the outer ways to find the useful tags.

I know the wiki is not gospel but I have invested some time in 
documenting how I think multipolygons should be handled "properly" (and 
how I tend to code multipolygon handling), here:


> Unfortunately it picked up "waterway=stream" from one of them, and I
> supported drawing them as polygons, so I ended up with several hundred
> square km of stream.

My description says:

"If the relation has no tags, look to the ways making up the outer 
rings. If these ways all have the same tags, use these for the 
multipolygon. If not, either try to merge them sensibly or refuse to 
process the relation."

In this case, using waterway=stream for the resulting polygon certainly 
violates the "merge them sensibly" rule, and osm2pgsql should have 
rejected the polygon if it could not find something that made better sense.

I tend to be against strict rules of any kind but when it comes to the 
question of what exactly a complex relation means I think it would be 
good to have one definition which every tool writer should aspire to 


More information about the dev mailing list