Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[roads] leisure=track should not automatically be area #2339

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 9 comments
Closed

[roads] leisure=track should not automatically be area #2339

openstreetmap-trac opened this issue Jul 23, 2021 · 9 comments

Comments

@openstreetmap-trac
Copy link

Reporter: schuetzm[at]gmx.net
[Submitted to the original trac issue database at 2.18pm, Thursday, 1st October 2009]

Closed ways with leisure=track should not automatically be rendered as areas, but only if they have area=yes set.

See #1900 for the same bug in osmarender.

@openstreetmap-trac
Copy link
Author

Author: Polarbear
[Added to the original trac issue at 11.03pm, Wednesday, 6th January 2010]

Supporting the ticket!

Stadiums often have pitches in the middle of the 400 m track, which are covered by the current area filling.

Example: http://www.openstreetmap.org/?lat=49.9004&lon=10.92902&zoom=17&layers=0B00FTF

Osmarender has this solved meanwhile.

@openstreetmap-trac
Copy link
Author

Author: rasmusv
[Added to the original trac issue at 8.22pm, Wednesday, 8th September 2010]

The same problem exist in my area as well: http://www.openstreetmap.org/?lat=56.17117&lon=10.16251&zoom=17&layers=M

Drawing the leisure=track tag as an area is definitely not a good way to represent a running track. I think it would be more correct to assume it is a way drawn as a closed loop and render it like if it was tagged with highway=track. And then let people fill up the middle with other things if they like. Of course we could do that outselves, but thats tagging for the renderer:/.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 7.11pm, Friday, 24th September 2010]

Since r21762, leisure=pitch always renders on top of leisure=track.

Assuming it's a closed way and not an area is not that clear-cut: http://www.openstreetmap.org/browse/way/46157210

@openstreetmap-trac
Copy link
Author

Author: schuetzm[at]gmx.net
[Added to the original trac issue at 11.11am, Saturday, 25th September 2010]

Reopening, as the tracks are still always rendered as areas (if I interpret the change and your comment correctly). Tracks should be linear by default, except when they have area=yes set, the same as for highways.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 11.30am, Saturday, 25th September 2010]

They are still drawn as areas. I explained it's not that easy to switch to a closed loop rendering.

Leisure keys are presumed to be areas. We cannot currently see the difference between those with area=yes and those without area=*.

The other issue, of pitches hidden by tracks, has been resolved some time ago.

@openstreetmap-trac
Copy link
Author

Author: rasher
[Added to the original trac issue at 3.40pm, Sunday, 26th September 2010]

Isn't the inability to render as area or not based on the area tag, rather than simply assuming all leisure keys are areas, a problem that needs to be solved then, rather than closing the ticket when the problem outlined in the report has not been solved in any way? Or at least explain why leisure=track should always be rendered as an error.

leisure=track can quite obviously (to me) be both an area or a way.

@openstreetmap-trac
Copy link
Author

Author: rasher
[Added to the original trac issue at 3.41pm, Sunday, 26th September 2010]

s/error/area/ (my kingdom for the ability to edit my comments)

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 5.18pm, Sunday, 26th September 2010]

The inability to handle leisure=track default as line stems from osm2pgsql. It sees every leisure feature as 'potential polygon' and will create it as a polygon when it forms a closed loop. We can not discern between those having area=yes and those without area key. The only way to currently force it as a line is to add area=no to those non-area types.

I'll keep this open, then, hoping that we get more flexibility from osm2pgsql in the future.

@openstreetmap-trac
Copy link
Author

Author: math1985
[Added to the original trac issue at 2.13pm, Monday, 26th May 2014]

This issue is now being discussed on Github: gravitystorm/openstreetmap-carto#574
Therefore, I will close it here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant