
Am 12.02.2010 20:06, schrieb Carlos Dávila:
WanMil escribió:
Compiling Spain I get several warnings similar to the one below, that point to data that are correct (or it seems to me).
|2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/319017 contains errors. 2010/02/12 09:26:39 ADVERTENCIA (MultiPolygonRelation): 63240004.osm.gz: Polygon 4611686018427391078[5P : (44132028[5P]) carries role inner but is not inside any outer polygon. Potentially it does not belong to this multipolygon.
|Reported way (hole in the building) lacks in the resulting map. Is it a know bug? Another question, why are polygons so deformed in MapSource compared to Mapnik?
Carlos,
the way http://www.openstreetmap.org/browse/way/44132028 overlaps the outer way of multipolygon http://www.openstreetmap.org/browse/relation/319017. If we look keenly on the definition of the multipolygon relation (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) this is not allowed. The current implementation of mkgmap does not support this.
Way 44132028 doesn't really overlap the outer polygon. They are separated some 25 cm, but mkgmap seems to consider them overlapping.
~25cm is much below mkgmap resolution (I think so...)
But it is widely used. There is a patch (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/007086.html) which is not yet committed and which fixes the problem. I think it will be committed within the next days.
I'll test it and give feedback
Thanks! That will speed up the commit.
The deformations do not look good. I think the problem is that mkgmap rounds the exact OSM coordinates to lower resolution garmin coordinates.
May it be also the origin of the overlapping problem in the above case?
Yes, propably.