Hi Jon, Jon Burgess wrote:
> I believe (a). The wiki documentation for multipolgons has two slightly > contradictory recommendations: Yeah - I just stumbled upon that...given the discussion it certainly seems like tagging the relation is better than tagging the way... - If we have a multipolygon, understanding the way without the relation and sibbling ways is going to be impossible (that is, the results will be spatially incorrect) in all but a very few cases. So I think clients need to be multipoylgon aware. - Better to have the tags on the relation and not have any issues of ambiguity. Tagging the underlying ways seems like a way to get inconsistent data. > That would be a good thing to do. Sometimes there is more than one way > to tag something and this does not necessarily mean that one of them is > incorrect. I will try to output a list of problems as I process the file. > If however the relation was also tagged, perhaps with a boundary tag > describing the name of the region then it would ignore the tags on the > ways. Does pgsql exclude the way as a way-area due to its membership in a multipolygon relation? What I mean by this is: I have a closed way with landuse=water, which is a lake in its own right. I then put it in a multipolygon relation. If I understand correctly, the lake from a single way is an "area" and can be parsed as such...its area would then be re-processed when we handle the multipolygon, which might have different tags. Or do data interpreting clients have to recognize the way in the relation and exclude its interpretation as an area? This seems like an inconsistent thing to do, particularly since holes can be areas in their own right. cheres ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ X-Plane Wiki: http://wiki.x-plane.com/ Scenery mailing list: [email protected] Developer mailing list: [email protected] _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
