Proposal: Multipolygon handling and line based multipolygons
The latest question about the boundary handling of multipolygons encouraged me to start another try to fix the problem in mkgmap (please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008976.html). Now I have another idea. The problem is: The resulting multipolygons usually are used as polygons. But some should only be used for the line processing (country borders). The multipolygon algorithm creates artificial polygons which are annoying if you want to use them as lines: you get artificial borders inside your country. My solution: The mp algorithm adds a tag mkgmap:styleusage=polygon to all artificially created polygons. Additionally it duplicates all input ways of the multipolygon, tag them with the mp tags and add mkgmap:styleusage=line. The style handling now applies line rules only if the tag mkgmap:styleusage=line is set or if it is completely unset. The same with polygons. With this solution the style writer can decide on its own if he wants to use the polygon information or the line information of the multipolygon. 2nd advantage: the style writer need not to change any existing styles as this new feature is handled internally in mkgmap. 3rd advantage: the line information of properly tagged multipolygons could also be used if the multipolygon is not completely contained in the tile. This if often the case for country boundaries. The --process-boundary-relations option of mkgmap would become needless. I am not an expert in styles so maybe I have missed something?!? What do you think about my idea? WanMil
WanMil (wmgcnfg@web.de) wrote:
The latest question about the boundary handling of multipolygons encouraged me to start another try to fix the problem in mkgmap (please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008976.html).
Now I have another idea. The problem is: The resulting multipolygons usually are used as polygons. But some should only be used for the line processing (country borders). The multipolygon algorithm creates artificial polygons which are annoying if you want to use them as lines: you get artificial borders inside your country.
My solution: The mp algorithm adds a tag mkgmap:styleusage=polygon to all artificially created polygons. Additionally it duplicates all input ways of the multipolygon, tag them with the mp tags and add mkgmap:styleusage=line. The style handling now applies line rules only if the tag mkgmap:styleusage=line is set or if it is completely unset. The same with polygons. With this solution the style writer can decide on its own if he wants to use the polygon information or the line information of the multipolygon. 2nd advantage: the style writer need not to change any existing styles as this new feature is handled internally in mkgmap. 3rd advantage: the line information of properly tagged multipolygons could also be used if the multipolygon is not completely contained in the tile. This if often the case for country boundaries.
The --process-boundary-relations option of mkgmap would become needless.
I am not an expert in styles so maybe I have missed something?!? What do you think about my idea?
WanMil _______________________________________________
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. 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. Hope that made sense, -- Charlie
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
Hi WanMil, Thanks so much for the fix. I have tried it so far on 2 style files and it works great. I can now also run the splitter overlap very high to allow for long distances between nodes and it still works. I even tried 50000 and it works. It even fixed the mutltiple border names. Normally it is so easy to find an error, so far I haven't yet found an error. Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Wednesday, 15 September 2010 6:11 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Proposal: Multipolygon handling andline based multipolygons
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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I forgot to mention, I finally worked out how to apply a patch, it is now very easy. I use TortoiseSVN to download the SVN then use TortoiseSVN with its inbuilt apply patch. Then I use ANT to compile the build.xml. Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Markus Sent: Wednesday, 15 September 2010 7:59 PM To: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Proposal: Multipolygon handlingandline based multipolygons Hi WanMil, Thanks so much for the fix. I have tried it so far on 2 style files and it works great. I can now also run the splitter overlap very high to allow for long distances between nodes and it still works. I even tried 50000 and it works. It even fixed the mutltiple border names. Normally it is so easy to find an error, so far I haven't yet found an error. Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Wednesday, 15 September 2010 6:11 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Proposal: Multipolygon handling andline based multipolygons
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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Sounds like a good idea to add the mkgmap:styleusage=line and mkgmap:styleusage=polygon. I also like charlies ideas. Not adding linear tags to the created polygons, as these should only be lines anyway. But an extra tag added also would allow filtering in the style if any liner ways are missed within the multipolygonto the Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 11 September 2010 9:23 PM To: Development list for mkgmap Subject: [mkgmap-dev] Proposal: Multipolygon handling and line basedmultipolygons The latest question about the boundary handling of multipolygons encouraged me to start another try to fix the problem in mkgmap (please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008976.html). Now I have another idea. The problem is: The resulting multipolygons usually are used as polygons. But some should only be used for the line processing (country borders). The multipolygon algorithm creates artificial polygons which are annoying if you want to use them as lines: you get artificial borders inside your country. My solution: The mp algorithm adds a tag mkgmap:styleusage=polygon to all artificially created polygons. Additionally it duplicates all input ways of the multipolygon, tag them with the mp tags and add mkgmap:styleusage=line. The style handling now applies line rules only if the tag mkgmap:styleusage=line is set or if it is completely unset. The same with polygons. With this solution the style writer can decide on its own if he wants to use the polygon information or the line information of the multipolygon. 2nd advantage: the style writer need not to change any existing styles as this new feature is handled internally in mkgmap. 3rd advantage: the line information of properly tagged multipolygons could also be used if the multipolygon is not completely contained in the tile. This if often the case for country boundaries. The --process-boundary-relations option of mkgmap would become needless. I am not an expert in styles so maybe I have missed something?!? What do you think about my idea? WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Sorry about the unfinished message. Sounds like a good idea to add the mkgmap:styleusage=line and mkgmap:styleusage=polygon. I also like charlies ideas. Not adding linear tags to the created polygons, As these I think should only be lines anyway. But an extra tag added also would allow filtering in the style if any liner ways are missed being excluded within the multipolygon algorithm. Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 11 September 2010 9:23 PM To: Development list for mkgmap Subject: [mkgmap-dev] Proposal: Multipolygon handling and line basedmultipolygons The latest question about the boundary handling of multipolygons encouraged me to start another try to fix the problem in mkgmap (please read http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q3/008976.html). Now I have another idea. The problem is: The resulting multipolygons usually are used as polygons. But some should only be used for the line processing (country borders). The multipolygon algorithm creates artificial polygons which are annoying if you want to use them as lines: you get artificial borders inside your country. My solution: The mp algorithm adds a tag mkgmap:styleusage=polygon to all artificially created polygons. Additionally it duplicates all input ways of the multipolygon, tag them with the mp tags and add mkgmap:styleusage=line. The style handling now applies line rules only if the tag mkgmap:styleusage=line is set or if it is completely unset. The same with polygons. With this solution the style writer can decide on its own if he wants to use the polygon information or the line information of the multipolygon. 2nd advantage: the style writer need not to change any existing styles as this new feature is handled internally in mkgmap. 3rd advantage: the line information of properly tagged multipolygons could also be used if the multipolygon is not completely contained in the tile. This if often the case for country boundaries. The --process-boundary-relations option of mkgmap would become needless. I am not an expert in styles so maybe I have missed something?!? What do you think about my idea? WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
charlieï¼ cferrero.net -
Markus -
WanMil