logo separator

[mkgmap-dev] Bogus warnings about intersected ways in multipolygons

From WanMil wmgcnfg at web.de on Tue Jan 26 21:28:54 GMT 2010

Am 26.01.2010 20:00, schrieb Marko Mäkelä:
> Hi WanMil,
>
> thank you for having a look.
>
> On Tue, Jan 26, 2010 at 07:05:39PM +0100, WanMil wrote:
>>> On Mon, Jan 25, 2010 at 09:39:56PM +0000, Adrian wrote:
>>>> I don't think these warnings are bogus. Mkgmap definitely has problems
>>>> with multipolygons. The Languedoc-Roussillon extract (southern France)
>>>> from Geofabrik provokes about a hundred of these warnings. But I believe
>>>> that the intersected ways are being generated by mkgmap and that the OSM
>>>> data is OK.
>>>
>>> That is what I meant by "bogus": the input data is correct, and mkgmap
>>> is doing something wrong.  The browse URL that I posted was for a block
>>> house in Helsinki, nowhere near my tile boundaries.
>>>
>>> 	Marko
>>
>> Marko,
>>
>> I tried to reproduce your problem but I wasn't able to.
>
> Me neither.  It must have been bad map extract then, even though I can't
> immediately see how.  I tried to check the history of the relation and
> the ways back then, but it could be that someone had moved a node and back
> again so that the dump was bad but the live data looked OK.  I did not check
> the history of each node.  Or then again, this may have been fixed in
> mkgmap r1512, which I ran today.  For what it is worth, this the only
> message that I could find in my logs about 5828:
>
> 2010/01/23 14:24:02 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/5828 contains intersected ways
>
> Here is another case for you:
>
> 2010/01/26 13:08:41 SEVERE (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/48542 contains intersected ways
>
> The ways do not really intersect, but they overlap.  It is a Japanese
> garden (leisure=garden) within a landuse=residential polygon.  Could
> you omit the warning for this case, or at least replace the "intersected"
> with "overlapping"?  ASCII art for the lines:
>
> RRRRRRRRRRggggRRRRRRRR
> R         g  g       R
> R         g  g       R
> RRRRRRRRRRggggRRRRRRRR
>
> R=residential, g=garden.  I believe that you would get a similar situation
> if a "more valid" multipolygon were cut by a tile boundary (T), like this:
>
> RRRRRRRRRRRRRRRRRRRRRR
> R                    R
> R         gggg       R
> R         g  g       R
> TTTTTTTTTTTTTTTTTTTTTT
> R         g  g       R
> R         gggg       R
> RRRRRRRRRRRRRRRRRRRRRR
>
> As far as I understand, you'd have to replace the
> TTTTTTTTTTTTTTTTTTTTTT with RRRRRRRRRRggggRRRRRRRR
> in each tile.
>
> I would not like to see any multipolygon warnings at tile boundaries.
> I understand that it is currently impossible to silence them at the
> unknown boundaries of the Geofabrik extracts, but I do get some warnings
> at tile-splitter boundaries too.  Would it be possible to silence them
> or somehow indicate that they occur at a tile border, so that I can
> filter out the warnings?
>
> Best regards,
>
> 	Marko

I analyzed the logfiles and found a possible reason.
I got the warnings for 
http://www.openstreetmap.org/browse/relation/10251. I created GPX files 
for this relation which is quite useful for analyzation purposes. The 
GPX files showed that the whole relation was outside the tile bounds and 
at least one point was missing in the outer polygon. However the outer 
polygon was closed. So the warning was correct but not useful in any way.
The relation was completely contained in another tile so it was rendered 
and handled correctly later on.

I have started to implement a better strategy on the tile boundaries. 
This will take some time until it is ready for commit.

The other problem with the japanese garden can be fixed. The algorithm 
must allow overlaying polygons. At the moment I see some performance 
issues for this, but I will have to test it. Maybe there is no issue.

As you proposed I will change and reduce the warnings shortly.
Thanks for your comments!

WanMil




More information about the mkgmap-dev mailing list