Hi All, I stumbled across an issue this week and I don't have a great solution to it, so I thought I'd share it here.
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've found this very common, especially with buildings. In fact, I used it as an example in my talk at SOTM-EU, where another application was showing buildings incorrectly - in some cases filling in the whole thing (tags-on-outer-ways) and missing the building entirely (tags-on-buildings). So both situations are established and we need to deal with them. 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. 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. Argh! But since no other map supports this particular level of micro-mapping, it appears that it's my map that's broken, so I've changed my styles to explicitly not support streams-as-polygons. But that's not fixing the general issue - people have a (strange) fascination with creating relations for all kinds of (strange) reasons, and that will only continue. Can anyone see a better way of handling this situation? Should I have drawn a line in the sand and demanded the relation in question was changed? Or is it an obligation on map makers to tread only in the footsteps of the main layer? I guess if osm2pgsql had picked a different outer way for the "useful" tags - say one with highway=pedestrian, and it showed up on the main style, then the relation would have been changed pronto. Cheers, Andy _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
