[OSM-dev] Tagging of multipolygons with holes within holes

[Igor Brejc]

On Wed, Oct 17, 2012 at 1:37 PM, Peter Wendorff
<wendorff at uni-paderborn.de>wrote:

>  Hi Igor.
> But if we're talking about topology, why (as I understand it) are you
> trying to force topological stuff in the multipolygon RELATION?
> That solves, well... nearly nothing.
> You have to do exactly the same work for any topological issues that are
> not described by a mp relation, e.g. because they aren't multipolygons, but
> distinct buildings, forests, water-surfaces or whatever.
> There you have to do exactly what you don't want to do here and where you
> want to have further restriction for multipolygon relations.
>
> I would suggest you to work on the progress towards area types to be part
> of the future api: discussion, decision and implementation.
> I would like to see additional topology introduced: along, beneath, ....
> are interesting, but yet difficult to get topological relations for osm
> data users.
>
> But: Keep in mind that editing should not become more difficult for
> mappers. If topology requires to assemble complex relations that's no
> option.
>
>
>
Hi Peter,

Maybe I haven't made myself clear: I haven't started this discussion to
propose any kind of change in the OSM data structures or "rules" how to tag
things. I'm merely trying to figure out ways to extract as much useful data
from the existing OSM data and structures as possible. The problem with
multipolygon handling is that it is a moving target. The rules have changed
a lot and are still changing. I know, since I've been implementing MP
processors ever since the first versions of Kosmos and every time I take a
look at the Wiki page, I find some new stuff that makes my MP processing
logic obsolete or not good enough. A lot of decisions have been made just
to prevent breaking existing behavior, I can understand that, but some of
those decision were not really good ones. So when anyone claims the OSM's
MP concept is simple and straightforward, I beg to differ ;)

Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20121017/08993c1b/attachment.html>