[mkgmap-dev] [mp: PATCH] Multipolygon handling - decomposed polygons

Sat Jan 9 18:55:06 GMT 2010

Johann,

thank you for you good explanations to the filter chain. It gives me a 
good overview how it works!

> What do you mean by mo code composign larger polygons?
> As far as I understand the thing, it combines an outer poylgon with an
> inner polygon to a poygon with an hole. But by definition the inner
> polygon has to be always smaller than the outer polygon. (BTW: What
> happens, if this is not the case, caused by wrong osm data??)

Oh, I was wrong. Polygons are not composed to larger polygons. Single 
unclosed lines are composed to polygons.
The error case: If the inner polygon touches or cuts the outer polygon 
nothing is done so far. Only a warning message is issued. This might be 
changed in future, so that the area of the inner polygon is removed from 
the outer polygon.

>
> So what will happen?
> If the inner polygon is small enough, then it will not be stamped out.
> This seems okay to me. If both of them are filtered out, then its ok too.
>> Mmh, 1st solution seems to be ok. In low resolutions mp code only cuts
>> out large inner holes. In this case it shouldn't matter if some small
>> pieces are cut from the large outer polygon.
>>
>>
> I think, 1st solution is exactly what we have now??

Not exactly. The current mp code removes tags from the single ways that 
are composed to polygons. While I am writing these lines I get the idea 
that I should change that. If a way has polygon tags they will not be 
used (is that right?). But if it has way related tags like 
highway=unclassified they are used and are missing if I am removing them.

>
> But I see a technical problem arise:
> In the filter chain there aren't any more tags or other information on
> how polygons are connected. There are only the raw polygon objects with
> coordinate data.

Do you mean the multipolygon information which polygons belong to the 
mulitpolygon relation is not available?
Or do you mean that there are no tags (like natural=forest) available?

>
> In my very private opinion the multipolygon handling should be done in
> the first stage, at it is now, and the splitting should be done in the
> filter chain after size and dp filter. But I see, that this could be
> problematic, as the splitting has given some performance boost to the MP
> code, so it will not be easy to extract this part of it.
>

Extracting this part should not be the problem. But I cannot say 
anything about performance. This has to be tested.

At the moment I will try to finish the mp code where it is. This should 
improve the situation very much compared to the current trunk.

After that we can start to move the splitting code to the filter chain 
which sounds like a good idea.

WanMil