Commit: r1867: Translate leisure=track into a line (footway) unless area=yes.
Version 1867 was commited by marko on 2011-02-28 11:03:17 +0000 (Mon, 28 Feb 2011) Translate leisure=track into a line (footway) unless area=yes.
On 28/02/2011 11:03, svn commit wrote:
Version 1867 was commited by marko on 2011-02-28 11:03:17 +0000 (Mon, 28 Feb 2011)
Translate leisure=track into a line (footway) unless area=yes.
Could you expand on what you mean by footway? I've recently tagged a running track (leisure=track) as closed way relations (inner & outer) to form an area but don't use the area=yes tag. Would that display correctly? Cheers Dave F.
How about cycling tracks (like race cycle tracks) leisure=track & sport=cycling maybe render those as highway=service / cycleway?
On Mon, Feb 28, 2011 at 11:26:39AM +0000, Dave F. wrote:
Could you expand on what you mean by footway?
I mean the same as highway=footway, or {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] My reasoning was that sports tracks may or may not be closed from the general public. When not in use, they could be used as shortcuts by pedestrians, but not necessarily for other means of transportation.
I've recently tagged a running track (leisure=track) as closed way relations (inner & outer) to form an area but don't use the area=yes tag. Would that display correctly?
The wiki http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack says that leisure=track is to be used on nodes and ways. This hints that you should add area=yes when you mean an area. When it comes to sport=cycling, I guess that we could add bicycle=yes, but are there really so many cycling tracks in the OSM data? Wouldn't it be simpler to add the bicycle=yes to the source data, to those tracks that are available for the general public outside sports events? Marko
On 28/02/2011 12:04, Marko Mäkelä wrote:
On Mon, Feb 28, 2011 at 11:26:39AM +0000, Dave F. wrote:
Could you expand on what you mean by footway? I mean the same as highway=footway, or {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
My reasoning was that sports tracks may or may not be closed from the general public. When not in use, they could be used as shortcuts by pedestrians, but not necessarily for other means of transportation.
But that would mean *all* linear leisure=tracks are rendered as footpaths. This is clearly incorrect. You should make use of the access tag to clarify public access A sports track (such as a running track) is still a sports track when not in use & should be rendered as so. 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.
The wiki http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack says that leisure=track is to be used on nodes and ways. This hints that you should add area=yes when you mean an area.
The majority of the wiki was written a while ago before relations were widely used. They are also written as a guide & not set in concrete. Multi polygon relations make the area tag redundant.
When it comes to sport=cycling, I guess that we could add bicycle=yes, but are there really so many cycling tracks in the OSM data? Wouldn't it be simpler to add the bicycle=yes to the source data, to those tracks that are available for the general public outside sports events?
Again, the access tag should be implemented. Dave F.
On Mon, Feb 28, 2011 at 03:01:57PM +0000, Dave F. wrote:
On 28/02/2011 12:04, Marko Mäkelä wrote:
On Mon, Feb 28, 2011 at 11:26:39AM +0000, Dave F. wrote:
Could you expand on what you mean by footway? I mean the same as highway=footway, or {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
My reasoning was that sports tracks may or may not be closed from the general public. When not in use, they could be used as shortcuts by pedestrians, but not necessarily for other means of transportation.
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).
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. The only exception is one that I implemented a while back, to hide service and emergency exit tunnels to a railway tunnel. 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. 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.
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.
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? Best regards, Marko
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.
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
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?
All polygons created by the multipolygon algorithm are tagged with mkgmap:stylefilter=polygon, which means that such tagged ways are only used with the polygon style. The source ways of the multipolygon are tagged with mkgmap:stylefilter=polyline, so that they are only handled by the line style. This allows to visualize boundaries although the boundary multipolygon is not fully contained in the tile. From my point of view, the area tag is relevant for tags that could either be used as line or as polygon. If you create a square tagged with highway=pedestrian the place inbetween could either belong to the pedestrian area (area=yes) or could be not accessible (area=no or not set). But I admit that the area tag was used in multiple variants and I am not a very up2date in OSM tagging guidelines. WanMil
Marko Mäkelä schrieb am 28.02.2011 13:04:
The wiki http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack says that leisure=track is to be used on nodes and ways. This hints that you should add area=yes when you mean an area.
The wiki http://wiki.openstreetmap.org/wiki/Map_Features also allows this tag for areas. It is a known problem, that the OSM data does not differentiate between lines and areas. And I don't think we should rely always on an area=yes tag to solve this mess. Gruss Torsten
participants (6)
-
Dave F. -
Marko Mäkelä -
Minko -
svn commit -
Torsten Leistikow -
WanMil