[OSM-talk] osm2pgsql multipolygon parsing

["Petr Morávek [Xificurk]"]

Dne 23.9.2013 11:59, Paul Norman napsal(a):
> Unless the closed way is a member of a multipolygon relation with no other
> tags on the relation - then you'll have a resulting area with a hole. This
> is a very well established means of tagging areas with holes (~22% of
> type=multipolygon relations have no other tags).

Yes, but if the relation has any[*] additional tags, you can't reliably
decide what was the intended purpose of this tagging. Imho the only
logical thing is to treat the relation and ways separately.
[*] Maybe some internal keys could be ignored, e.g. odbl, fixme, ...

> The issues raised originally in the ticket are best explored through
> examples
> 
> The first case is a way with natural=water and a MP relation with no other
> tags. Both old osm2pgsql (0.82) and latest master version from git create an
> area with a hole with natural=water on the area. There are no suggestions of
> changing this.

Agreed.

> The second is a way with natural=water and a MP relation with name=foo (with
> the way as a member). Old osm2pgsql created an area with a hole with
> natural=water, name=foo, latest master does too.

Is this really correct?
In case of the name=foo it is probably safe assumption, but how about
multipolygon relation with only access=* tag (or something similar)? How
do you decide, if it means the area with holes is
natural=water+access=*, or that the whole area (with no holes) is
natural=water and only some parts have access=*?

> The fourth is a way with natural=water and a MP relation with foo=bar. In
> old osm2pgsql this created an area without a hole, in latest master it
> depends on the .style file used for import.

The dependence on on the .style file bothers me, I think it's a mistake
and will ultimately come back to haunt us. If you don't care about some
features and delete the lines from your .style file, the multipolygon
parsing should not change.

--

I propose that:
1) By default the relation and ways are treated separately
 - relation creates polygon with tags from the relation and ways are
processed on their own.
2) If and only if the relation has only type=multipolygon tag go to
"backward compatibility mode". Copy over tags from outer ways that are
present on all of them and create polygon. Go over all member ways and
if all their tags are present on the created polygon, then mark them as
done, otherwise process them separately.

--

I have looked at all the multipolygon relations that do not have any of
the well-known polygon tags (the ones defined in default.style), this is
less than 27% of all the multipolygon relations. 85% of these relations
have type=multipolygon tag only, so the proposed change in fact affects
less than 4% of all the multipolygons.

More detailed breakdown of tags on multipolygons without well-known
polygon tags:
percentage	keys
85.5%		type
3.7%		ref,type,id_ob,adr_les
1.7%		type,name
1.5%		area,type,highway


Best regards,
Petr Morávek aka Xificurk