Wishlist: Better multipolygon error reporting
Hi, Lake Päijänne is probably the largest multipolygon relation in Finland, even after I split some named bays to separate natural=bay polygons or multipolygons. There is one error that I have not been able to figure out. JOSM is not complaining anything if I extract the relation from finland.osm.pbf with Osmosis and load to JOSM. The whole area is fully within the boundaries of my tile 63240005: 2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Multipolygon http://www.openstreetmap.org/browse/relation/1239779 [natural=water,type=multipolygon,name=Päijänne] contains errors. 2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Polygon 4611686018427683240(7P)(31081024[7P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. Could the message mention a coordinate of the faulty polygon? I am guessing that this message is due to the Garmin map resolution (about 5m). It would be nice to identify the problematic polygon, to confirm this. Or, maybe the JOSM Validator is not checking for inner polygons that are completely within another inner polygon. Marko
Hi Marko,
Hi,
Lake Päijänne is probably the largest multipolygon relation in Finland, even after I split some named bays to separate natural=bay polygons or multipolygons. There is one error that I have not been able to figure out. JOSM is not complaining anything if I extract the relation from finland.osm.pbf with Osmosis and load to JOSM. The whole area is fully within the boundaries of my tile 63240005:
2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Multipolygon http://www.openstreetmap.org/browse/relation/1239779 [natural=water,type=multipolygon,name=Päijänne] contains errors. 2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Polygon 4611686018427683240(7P)(31081024[7P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer.
This message tells you all, almost :-) Way 31081024 with 7 points is assigned with the role inner. But it is not an inner polygon. It lies completely within way 168463590 which also has role inner. This is not allowed in mps. So mkgmap assumes that way 31081024 has role outer and the tagging is a mistake. WanMil
Could the message mention a coordinate of the faulty polygon?
I am guessing that this message is due to the Garmin map resolution (about 5m). It would be nice to identify the problematic polygon, to confirm this. Or, maybe the JOSM Validator is not checking for inner polygons that are completely within another inner polygon.
Marko
On Thu, Jul 05, 2012 at 10:03:18PM +0200, WanMil wrote:
2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Polygon 4611686018427683240(7P)(31081024[7P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer.
This message tells you all, almost :-) Way 31081024 with 7 points is assigned with the role inner. But it is not an inner polygon. It lies completely within way 168463590 which also has role inner. This is not allowed in mps. So mkgmap assumes that way 31081024 has role outer and the tagging is a mistake.
Thanks, I fixed this now. Recently, Someone added lots of islands from Bing images (originally with natural=coastline) around the existing ones, which were added from Landsat images years ago. Where did you get the 168463590? By looking at the map? Best regards, Marko
On Thu, Jul 05, 2012 at 10:03:18PM +0200, WanMil wrote:
2012/07/05 21:37:39 WARNING (MultiPolygonRelation): 63240005.osm.pbf: Polygon 4611686018427683240(7P)(31081024[7P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer.
This message tells you all, almost :-) Way 31081024 with 7 points is assigned with the role inner. But it is not an inner polygon. It lies completely within way 168463590 which also has role inner. This is not allowed in mps. So mkgmap assumes that way 31081024 has role outer and the tagging is a mistake.
Thanks, I fixed this now. Recently, Someone added lots of islands from Bing images (originally with natural=coastline) around the existing ones, which were added from Landsat images years ago.
Where did you get the 168463590? By looking at the map?
Yes, I downloaded the mp with JOSM and looked around the way 31081024. You could also get the way number using the FINE debug level for multipolygons. In this level the contains matrix is printed (which polygon is inside which other polygons). But you will get that for all multipolygons and therefore it is not very useful. I think about a little change in the mp debugging. What do you think: You can set an environment variable (or a logging parameter? I don't know if that's possilbe). This variable contains a comma separated list of mps that should be traced, e.g. MP_TRACE=1239779,124484. For all mps listed in this variable all debug messages are printed out with a separate logger and log level INFO (or WARN or ERROR). This would make it possible to get detailed information about some mps without getting tons of logfiles. WanMil
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
I think about a little change in the mp debugging. What do you think: You can set an environment variable (or a logging parameter? I don't know if that's possilbe). This variable contains a comma separated list of mps that should be traced, e.g. MP_TRACE=1239779,124484. For all mps listed in this variable all debug messages are printed out with a separate logger and log level INFO (or WARN or ERROR).
This would make it possible to get detailed information about some mps without getting tons of logfiles.
This could work, sure. After the optimization work some months ago, mkgmap does its job very quickly, and I would not mind an extra run in cases like this. By the way, OsmAndMapCreator gives slightly different MP errors. But, it is about 100 times slower than mkgmap when converting Finland (admittedly, using only 1 CPU core). Best regards, Marko
participants (2)
-
Marko Mäkelä -
WanMil