[mkgmap-dev] Incorrect multipolygon warnings?

Sun Mar 28 20:47:31 BST 2010

> WanMil escribió:
>> Am 28.03.2010 17:24, schrieb Carlos Dávila:
>>
>>> WanMil escribió:
>>>
>>>>> Hi,
>>>>>
>>>>> Whilst processing Italy, I've been getting a lot of mp warnings like:
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz:
>>>>> Polygon 4611686018427439638 intersects itself. It is splitted into 2
>>>>> polygons.
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The
>>>>> polygon is composed of
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: -
>>>>> http://www.openstreetmap.org/browse/way/36433060
>>>>>
>>>>> I can't see anything wrong with this mp and the JOSM validator does not
>>>>> pick up on anything.  Is this an error with mkgmap's MP code or am I
>>>>> missing something?
>>>>>
>>>>>
>>>> Yes and no. While reading in the data from osm files mkgmap converts all
>>>> coordinates to the garmin internal format. This reduces the resolution
>>>> of the coordinates. So the multipolygon code works with other
>>>> coordinates than OSM. Due to this a polygon might intersect itself
>>>> although it does not in the original OSM data.
>>>>
>>>>
>>>>
>>>>> Here's another:
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz:
>>>>> Polygon 4611686018427439886 intersects itself. It is splitted into 2
>>>>> polygons.
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: The
>>>>> polygon is composed of
>>>>> 2010/03/27 13:57:27 WARNING (MultiPolygonRelation): 63242013.osm.gz: -
>>>>> http://www.openstreetmap.org/browse/way/36434237
>>>>>
>>> I also have a mp warning in which I can't see any error:
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> Cannot join the following ways to closed polygons. Multipolygon
>>> http://www.openstreetmap.org/browse/relation/2909
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52489521
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889739
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/11276547
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/11276563
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52288870
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52288868
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/51442603
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/11276562
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52489071
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52489520
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/52489515
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889860
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889776
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889848
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889700
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/51334155
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> - way: http://www.openstreetmap.org/browse/way/4889699
>>> 2010/03/28 14:32:08 ADVERTENCIA (MultiPolygonRelation): 63240002.osm.gz:
>>> Multipolygon http://www.openstreetmap.org/browse/relation/2909 does not
>>> contain any way tagged with role=outer or empty role
>>>
>>> If I check relation 2909 in JOSM it does have lots of ways tagged with
>>> role outer and they are connected in a closed polygon, apparently in the
>>> right order. Do you have any clue? May it be a
>>> clockwise/counterclockwise issue?
>>>
>>
>> Clockwise/Counterclockwise does not make any difference.
>> Probably this is a tile splitter problem and therefore the multipolygon
>> is not completely cotainted in the tile.
> Not a tile problem, but I've realized this mp is cut by geofabrik (it's
> in Spain/Portugal border). It is correctly processed when I compile full
> Iberian Peninsula map (from Europe excerpt), not just Spain or Portugal.
> Is there any workaround for these cases? (I have a lot more in
> Spain/France border).

Unfortunately not. The mp processing performs some simple autoclosing of 
unclosed polygons. This happens if the polygon can be closed without any 
self-intersections.

WanMil