[mkgmap-dev] multipolygon wih leisure=park does not render

Sat Sep 11 12:38:02 BST 2010

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-bounces at lists.mkgmap.org.uk
> [mailto:mkgmap-dev-bounces at 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
> <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 at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>