[mkgmap-dev] Commit: r1867: Translate leisure=track into a line (footway) unless area=yes.

Tue Mar 1 15:14:42 GMT 2011

Hi Dave,

On Tue, Mar 01, 2011 at 02:40:45PM +0000, Dave F. wrote:
>>> You should make use of the access tag to clarify public access
>> Can you clarify what you mean? The default style does generate map
>> elements that are access=private or access=no.
>
>So, why have you submitted your amendment which ignores the above?

I do not understand what you mean. Could it be that you do not see the 
difference between the "add" and "set" actions? "add" will not overwrite 
an existing key, but "set" will.

r1867 added this rule to the lines file:

+leisure=track & area!=yes { add highway=footway; name '${name} (${sport})' | '${name}' }

It changed the rule in the polygons file:

-leisure=track { name '${name} (${sport})' | '${name}' } [0x19 resolution 18]
+leisure=track & area=yes { name '${name} (${sport})' | '${name}' } [0x19 resolution 18]

>> The only exception is one that I implemented a while back, to hide 
>> service and emergency exit tunnels to a railway tunnel.
>
>Why would you want to do that? Emergency exits are useful!

Yes, those that are publicly accessible can be useful. I don't think 
that it is useful to clutter the map by underground features that are 
inaccessible by the general public. That would be railway tunnels (or 
underground railways). There is a 30km freight tunnel near my place. I 
once got confused by a service tunnel that I had extrapolated for the 
map, because the extrapolated underground access tunnel was very close 
to a visible and accessible way. The access tunnel is behind locked 
doors in a building that is inside a locked fence. The building and the 
way to it are visible on the map.

>> The translation (which you quoted above) already adds access=no and 
>> foot=yes if these keys are not already present.
>
>But, again, you're changing *all* when you don't know if they're also a
>footway?

Now I believe that I understood your point. Let us consider the lines 
file:

leisure=track & area!=yes
{ add highway=footway; name '${name} (${sport})' | '${name}' }

It appends ${sport} to an existing name, if name=* and sport=* are 
present. If there is no highway=* tag present, it will add 
highway=footway. If the way is already tagged as highway, this rule only 
affects the name.

Any added highway=footway would eventually trigger this existing rule:

highway=footway|highway=path|highway=steps
{add access = no; add foot = yes}
[0x16 road_class=0 road_speed=0 resolution 23]

This one adds the access=no and foot=yes if these keys are not present.  
(The source data can carry bicycle=yes, motorcar=yes, 
access=destination, whatever.)

>You're changing them from leisure=track to highway=footway even though 
>you don't know that they are.

We map a lot of things to 0x16. Other applicable types might be 0x0a and 
0x07. Which one would you prefer? Can you give an example?

>>> A sports track (such as a running track) is still a sports track 
>>> when not in use&  should be rendered as so.
>> The problem is the limited number of way types.
>
>I don't see the relevance of that for this discussion.
>There's sports tracks & footways along with access & foot=*.
>What more do you need in this case?

A concrete example of what should be translated differently.

>>> Multi polygon relations make the area tag redundant.
>> WanMil, could we automatically add area=yes to all multipolygon 
>> relation members? Or perhaps mkgmap:area=yes?
>
>Will that mess up the displaying of the hole created by the inner multi 
>polygon?

I think that it is a bad idea to use a linear feature in a multipolygon 
relation. I would say that it is an error in the data.

>I believe you submission should be reverted because it converts all 
>tracks to footways.

Sure, I can revert it if you give some examples (OSM way ids or 
combinations of way tags).

Best regards,

	Marko