Hi Marko, I've checked a few cases. The typical reason for a message like this: very small shape near http://www.openstreetmap.org/?mlat=60.261495&mlon=24.689112&zoom=17 signed area in high prec map units: 2816 is a shape close to a tile boundary or a shape that is produced by the mp-relation routines. In the latter case, the routines cut a shape into pieces to remove holes. Sometimes this produces micro-areas when the cutting line cuts the polygon into multiple pieces. Nothing is wrong with the OSM data, and the ShapeMergeFilter is able to merge these micro shapes again. I plan to rewrite that part of the code, but it will require a bit more work, so maybe this has to wait for the next autumn. For now, I've just lowered the severity to debug level. Gerd
Date: Mon, 17 Mar 2014 22:45:54 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Warnings about hyper-precise multipolygons
Hi Gerd,
if you are talking about the messages from ShapeMergeFilter: A possible reason is a self intersecting polygon. The filter assumes that shapes are not self intersecting, but it doesn't test this yet.
About a week ago, I got a message that I thought was about merging adjacent (non-overlapping) shapes that carry identical tags. I cannot find such a message now. Here would be two examples of this:
http://www.openstreetmap.org/browse/relation/1225936 http://www.openstreetmap.org/browse/relation/1232121
These are hyper-precise multipolygons with two circles. Both the outer ring (actually, the relation) and the inner ring carry the same tag landuse=grass. Only the value of the golf=* attribute differs, but this does not matter to the default style.
There used to be two polygons for the inner circle: the role=inner polygon with no tags, and a duplicate polygon with the tags landuse=grass,golf=green. I deleted the duplicate polygon and moved the tags to the role=inner polygon. Tomorrow or the day after, I should see if the mkgmap message is changing.
There still are a few hyper-precisely mapped multipolygons, for which mkgmap is emitting messages. It is no problem for me to keep these relations in my ignore list. I usually monitor the output with "grep -vf logging.ignore mkgmap.log.0". Many relations that were on my ignore list are no longer generating errors. Either the data has been changed, or the higher precision is helping, or both.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev