On Mon, 2008-03-10 at 22:16 +0100, Frederik Ramm wrote:
> Hi,
>
> > If all the rings were closed and the roles where correctly defined then
> > there is a relatively simple algorithm to reconstruct the multipolygons
> > without needing too much memory or CPU overhead.
>
> I may be a bit slow here but couldn't we then just one-by-one fix the
> existing multipolygons so that they have proper roles and the outer
> ring is closed (beats me how anyone could think that you can have a
> polygon with a hole where the outer ring is NOT closed but if you say
> that's what people did...).
I don't think it was human design. It was how the 0.4->0.5 conversion
process dealt with un-ordered segments in ways. The consecutive segments
were all made into a way. Each time segments appeared which did not
appear to join with the others it was assumed these were a different
ring and a multipolygon relation was created to link the ways.
The conversion process could not work out the role of each of these ways
and duplicated the tags across all of them.
> I would expect that all tools working with multipolygons in one way or
> another should not require any changes. Indeed many probably make the
> assumption that the outer ring is closed anyway...
The original multipolygons created by the conversion above all had the
same tags and no defined roles. Adding the defined roles and then adding
a condition that the multipolygon rendering is to be determined by the
tags on the way with the "outer" role only is a deviation from the
previous data model. osm2pgsql will be broken by new interpretation of
multipolygons.
As I mentioned before, I am not against change. I'd be really happy to
see this rationalisation occur. It will eventually result in a cleaner
data model and less code in osm2pgsql. The transition period does risk
breaking what we have already and this is what I'm trying to avoid.
Jon
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
