Re: [mkgmap-dev] Proposal: Multipolygon handling and line based multipolygons
WanMil (wmgc...@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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygon wih leisure=park does not render
Hi Markus,
the boundary multipolygons are a real problem. The
--process-boundary-relations option is only a quick hack to avoid
problems with the artificially generated lines of the multipolygon
algorithm.
Boundaries are used as polygons (colour the area of the boundary) but
also as lines (mark the border of a country or a national park). The
first usage is supported by the multipolgyon handling whereas the second
one is not supported. Yeah multipolygon supports polygons but not lines.
The problem arises if one tries to combine both usages. Example: use a
style file that draws lines around countries but also colour the areas
of national parks. Then you get artificial country border lines created
by the multipolygon algorithm. Bad luck.
I don't know much about the style handling so there may be other
problems or maybe a solution for this.
I propose to tag things not to suit the renderer. The renderer or map
generator should become more intelligent if there is a problem. I will
write a separate mail with a proposal how we can get this fixed.
Thanks for you questions. It's good to have some feedback about problems!
WanMil
> Hi WanMil,
>
> A question on boundary tags?
>
> I have lately been using the great maps from openmtbmap.org and the national
> parks that don't need a multipolygon appear, but the national parks that do
> need a multipolygon don't appear. I assume this is because of the
> boundary=national_park tag in the multipolygons.
>
> I am wondering if the best option would be to remove the
> boundary=national_park and only have leisure=nature_reserve in the
> multipolygons of national parks I have added so then if someone doesn't add
> the --process-boundary-relations they will still get the national parks.
>
> Regards,
>
> Markus_g
>
> -Original Message-
> From: mkgmap-dev-boun...@lists.mkgmap.org.uk
> [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of WanMil
> Sent: Thursday, 26 August 2010 2:52 AM
> To: Development list for mkgmap
> Subject: Re: [mkgmap-dev] multipolygon wih leisure=park does not render
>
> Hi Jeroen,
>
> the reason for this is simple. The multipolygon algorithm need to decide
> if the mp is fully tagged or if the tags need to be taken from the mp
> ways. At the moment the mp algorithm just checks if one of the tags
> ["boundary", "natural", "landuse", "land_area", "building", "waterway"]
> is set. As you see the "leisure" tag is missing. Therefore the mp tags
> are ignored and the mp uses the tags from the ways.
>
> I will post a patch soon that adds "leisure" to the mp tags although
> that doesn't fix the real problem. The mp algorithm needs a list of all
> polygon tags or better an algorithm to decide that the mp is tagged
> appropriately. The definition of mps is not very accurate in this point.
>
> One note about the rumours in this thread:
> * multipolygons are always processed
> * --process-boundary-relations ignores the mps with boundary=*
>
> Have fun!
> WanMil
>
>> Hello all,
>> I'm new here, but did not know where else to go. Recently, I noticed (at
>> least) one multipolygon I created near me did not render with mkgmap
>> r1655 or r1669. I did some research, but don't know what to do next.
>> The polygon that does not render is 1022941 [1]. Mapnik renders it OK [2].
>> Another one, very similar does render:
>> http://www.openstreetmap.org/browse/relation/976305 (version 1)
>> Changing the order of the members in the multipolygon (in a local OSM
>> file) makes no difference.
>> Removing all tags from the members also does not solve the issue.
>> Changing tags for the relation from leisure=park to
>> landuse=recreation_ground does enable rendering, as does landuse=park.
>> Changing the tags in the style definition (polygons file, "leisure=park
>> {set landuse=park}", or same line in relations file) is no solution.
>> The Wiki does mention leisure=park as a possible tag [4] and I find it
>> logical. Any ideas how to get this rendered (without editing the OSM
>> database)?
>> [1] http://www.openstreetmap.org/browse/relation/1022941 (version 1)
>> [2]
>> http://www.openstreetmap.org/?lat=51.916293&lon=4.421655&zoom=18&layers=M
>
>> [3] http://www.openstreetmap.org/browse/relation/976305 (version 1)
>> [4] http://wiki.openstreetmap.org/wiki/Map_Features#Leisure
>> Thank you,
>> J-.
>> Jeroen Muris
>>
>>
>>
>> ___
>> 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
>
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
On Sat, Sep 11, 2010 at 06:41:48AM +0100, char...@cferrero.net wrote: >> Do we have a bug tracking system or a wiki page for tracking this >> kind of long-term, hard-to-implement feature requests? > >There's this: http://wiki.openstreetmap.org/wiki/Mkgmap#Known_issues Charlie, thank you for the hint. Now there is http://wiki.openstreetmap.org/wiki/Mkgmap#Relations discussing the limitations related to relations that I have thought of. It also links to the page http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules#apply where the substitution $(variable_name) has been documented. Now that I wrote http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules#apply_once, all of this thread should be summarized on the mkgmap wiki pages. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tag values of relations and tag values of its members
On Sat, Sep 11, 2010 at 08:53:48AM +0200, Torsten Leistikow wrote: >In ActionReader there is also an apply_once command included. Can this >be used to prevent the forward/backward-doubling? Or what is the >intended use of apply_once vs. apply? I implemented it when I started playing with relations: r1464 | marko | 2010-01-04 17:11:48 +0200 (Mon, 04 Jan 2010) | 2 lines Implement apply_once for applying commands once on relation members, even if the relation contains the members multiple times in a matching role. This would only help in case a bus route relation was defined in a single relation comprising both ways. If we have one relation per direction, every member would be included only once per relation anyway. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
