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 _______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk