Hi,
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:
http://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm
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
implement.
Bye
Frederik
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
