Am 17.10.2012 10:02, schrieb Igor Brejc:
On Wed, Oct 17, 2012 at 9:40 AM, Frederik Ramm <[email protected]
<mailto:[email protected]>> wrote:
The area of the "hole within the hole" does not require special
tagging, as it is covered by the multipolygon itself. If you have
a forest with a hole in a hole, then that hole in a hole is forest
as well.
True, but you need to determine that geometrically (see my previous
answer) and then apply the tagging rules down the "holes hierarchy".
Most current applications don't need to distinct between a hole in a
hole (or an "inner outer way") and a second outer way beneath the first
one, as most current applications don't care about the topology, but on
the geometry - and there it's only of interest which parts of the canvas
to fill and which not.
For the topology interpretation again the interpretation of a way as
"hole in a hole" isn't helpful either, as more often you will have
different objects inside that you have to consider to be that hole in
the hole, without a multipolygon being in place.
Therefore it's necessay to implement the logic Frederic described above
nevertheless.
If you are, on the other hand, thinking of a "lake in the middle
of a meadow in the middle of a forest" situation, then this is not
"hole in a hole" - the forest has one hole which is the meadow,
and the meadow has one hole which is the lake. You would have
three ways:
F - tagged as forest
M - tagged as meadow
L - tagged as lake
and two multipolygons
MP1: outer=F, inner=M
MP2: outer=M, inner=L
Yes, if you split it in two separate multipolygons, then it's clear.
But the problem is that Wiki does not explicitly forbids (just
recommends not to) doing it all in a single multipolygon, quote:
Such cascading is still recommended when the "island" in the
middle is something else than the area on the outside, but where
the "island" is the same stuff it can just be made a hole in the hole.
And where's the problem?
The island is part of the area described by the multipolygon, as every
other outer way is, too.
It can be handled exactly the same as long as you don't want to do
special stuff according to topology, but then again topology is missing
for most osm model elements, yet (or: you have to interpret it from the
geometry yourself).
regards
Peter
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
