On 28/02/2011 16:01, Marko Mäkelä wrote:
On Mon, Feb 28, 2011 at 03:01:57PM +0000, Dave F. wrote:
But that would mean *all* linear leisure=tracks are rendered as footpaths. This is clearly incorrect. Previously, the linear leisure=track were not rendered at all (or they were rendered as polygons, before WanMil committed the polygon-closing patch).
I'm not sure what relevance that has to your amendment or my comment above.
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?
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!
What is displayed on the map is not necessarily accessible by the general public.
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?
If the source data carries foot=no, then the line should not be routable at all. If it carries some access tags, then the way is available for routing in those modes of transport.
But it should be rendered as a track. You're changing them from leisure=track to highway=footway even though you don't know that they are.
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?
If there is a defined public way that is occasionally used as a sports track (mountain bike track, for example) then that track could be put into a route relation. Right. This is even more so with seasonal tracks, such as Nordic skiing routes or snowmobile routes. The underlying ways may be paths or roads in summer, or they may be in the middle of lakes or agricultural fields. Relations come to the rescue.
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 believe you submission should be reverted because it converts all tracks to footways. Cheers Dave F.