Wrong multipolygon warnings
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. 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. The deformations do not look good. I think the problem is that mkgmap rounds the exact OSM coordinates to lower resolution garmin coordinates. WanMil
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.
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
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?
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.
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1 < mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap. WanMil
WanMil escribió:
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1 < mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap.
Yes, I tried to patch the source code. My knowledge is enough for that ;-)
Am 12.02.2010 21:57, schrieb Carlos Dávila:
WanMil escribió:
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1< mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap.
Yes, I tried to patch the source code. My knowledge is enough for that ;-)
Ok, this was a silly question. But it was the only idea I have... Maybe there is a problem that the first patch was against rev 1563. I have attached a patch for revision 1568. Hopefully this will work...?!? WanMil
WanMil escribió:
Am 12.02.2010 21:57, schrieb Carlos Dávila:
WanMil escribió:
I'll test it and give feedback
Thanks! That will speed up the commit.
I'm not very fit with patches. I tried |patch -p 1< mp_linesoverlapping_v1.patch| within mkgmap root directory, but it didn't work |Hunk #1 FAILED at 38. Hunk #2 FAILED at 397. Hunk #3 FAILED at 407. Hunk #4 FAILED at 494. Hunk #5 FAILED at 509. Hunk #6 FAILED at 648. Hunk #7 FAILED at 671. Hunk #8 FAILED at 698. Hunk #9 FAILED at 843. Hunk #10 FAILED at 945. Hunk #11 FAILED at 1028. Hunk #12 FAILED at 1071. Hunk #13 FAILED at 1085. Hunk #14 FAILED at 1119. Hunk #15 FAILED at 1129. Hunk #16 FAILED at 1171. Hunk #17 FAILED at 1183. Hunk #18 FAILED at 1227. Hunk #19 FAILED at 1259. Hunk #20 FAILED at 1442. Hunk #21 FAILED at 1462. 21 out of 21 hunks FAILED| Can you give me some hint?
I am also no expert for patching. I use the Eclipse patch so I don't know any parameters. One basic question: Did you patch the source code? Patching does not work with the binary distribution. You must patch the source code and recompile mkgmap.
Yes, I tried to patch the source code. My knowledge is enough for that ;-)
Ok, this was a silly question. But it was the only idea I have... Maybe there is a problem that the first patch was against rev 1563.
I have attached a patch for revision 1568. Hopefully this will work...?!? Finally I could apply your patch moving it to the right directory. I'll test it tomorrow and give feedback.
WanMil ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
participants (2)
-
Carlos Dávila -
WanMil