[mkgmap-dev] Proposal: Multipolygon handling and line based multipolygons
From WanMil wmgcnfg at web.de on Tue Sep 14 21:41:12 BST 2010
> > That sounds like a good proposal. Another, possibly > conceptually-related problem with the mp code is as follows: > Consider a multipolygon with one outer way having the tags > barrier=fence > landuse=farm > and one inner way having the tag > natural=water > > The mp splits this into two outer polygons with landuse=farm and > barrier=fence and one inner polygon with natural=water. The problem > is that now the fence no longer follows the (outer) ways it was > originally designed to follow, but also follows the synthetic > orthogonal ways created by the mp code. If the style rules process > both landuse=farm (in the polygon ruleset) and barrier=fence (in the > lines ruleset) then you get an unwanted, synthetic fence being created > where none really exists. Yes, that's a nice side effect of the patch I posted. Although strictly speaking the tagging of your example is wrong. If a member way should have non polygon related tags the multipolygon must be tagged instead of the members. So the mp should have landuse=farm and the outer way should be tagged with barrier=fence. This already works without the patch. But I know that lots of such taggings exist in the OSM data. > > Having the mp code add a new tag to synthetic ways created as part of > multipolygon splitting would be one way of tackling this problem (by > subsequent re-writing of the style rules). The other would be to > avoid adding barrier=fence (or other such linear tags) to synthetic > ways created as part of polygon splitting. Good news: you don't need to rewrite your style rules. This is done automatically by the patch. Could you please test the patch and give some feedback? Thanks! WanMil
- Previous message: [mkgmap-dev] Proposal: Multipolygon handling and line based multipolygons
- Next message: [mkgmap-dev] Proposal: Multipolygon handling andline based multipolygons
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list