[mkgmap-dev] Incorrect multipolygon warnings?

Sun Mar 28 16:24:09 BST 2010

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?