Investigate leisure=track

[pnorman]

leisure=track doesn't render (example)

I think that's expected behaviour, leisure=track is supposed to be treated as line, not area and the line rendering hasn't been defined yet.

#1504 (comment)

• Check if leisure=track should be a polygon tag or not
• Adjust styling to handle changes

---

Shouldn't we already have linestring leisure=track coverage for non-closed ways?

[kocio-pl]

In lua branch this track area is not rendered, but this track area is.

[matthijsmelissen]

I'm against a semantics where closing a linestring (or for example joining two semicircles) suddenly changes the interpretation. We don't do that for any other type of object either.

I think there are only two possible semantics:

1. The tag implies area, leisure=track as unclosed linestring is invalid
2. The tag does not imply area; then we should require an area=yes tag on closed linestrings that signify areas

Many tracks have currently been tagged as linestring, so I think the second interpretation is the most sensible.

Thanks @kocio-pl for starting the discussion on tagging, by the way.

[polarbearing]

Agree. Making an unclosed linestring invalid as in 1) would invalidate existing unclosed jogging tracks. Changing the rendering of closed lines to "no filling" leaves them valid and visible, thus they can be improved if necessary.

However can still I assume that a multipoly with no area tagging would be assumed an area and filled, or would that contradict 2) ?

[matthijsmelissen]

However can still I assume that a multipoly with no area tagging would be assumed an area and filled, or would that contradict 2) ?

I think that's a bad idea, as that would be "a semantics where closing a linestring (or for example joining two semicircles) suddenly changes the interpretation".

[kocio-pl]

FYI: I've started fixing objects tagged like these and it seems a popular tagging habit to draw a line around the track instead in the middle (as we do with highways) or to create a proper multipolygon - probably this is tagging for rendering.

[polarbearing]

@math1985 - not sure what you mean. How could a multipoly with an outer and an inner ring be interpreted as a way and not an area? The purpose of such MP is to punch the inner area out of the outer area, so I see area=yes as implicit.
@kocio-pl - what exactly are you fixing into what?

[mboeringa]

or to create a proper multipolygon - probably this is tagging for rendering.

@kocio-pl : is see no reason why a track couldn't be a multipolygon. In fact, I see little if any use of a track in terms of a line element, a multipolygon makes much more sense.

Why?:

Simple: line elements only make sense in the context of routing in routing applications, or low zoom display. Neither is the case for the tag leisure=track. There is no sense in routing across an athletics track, you reach the finish automatically ;-). Neither is there much sense in low zoom display of tracks, e.g. at scales smaller than +/-1:100k

There is sense in seeing the actual surface of the track being displayed at high zoom as a multipolygon. It is just another nice high zoom surface feature showing the actual extent of the feature, similar to displaying other high zoom features like highway=pedestrian. These type of features should be part of a large scale map.

Actually, I see tracks as line elements only as a redundant historic feature of OSM, when we didn't have the large scale detail of OSM that we have now. I expect most of them to be replaced by more sensible multipolygons (and that is what I would do when encountering a track defined as only a single way along its outer extent: add an inner and create a multipolygon).

[kocio-pl]

Sorry for not being clear enough.

@polarbearing I fix the objects in my hometown, which have half-baked tagging - and I wrote here to let you know that this problem is very popular.

@mboeringa I meant "or instead of creating a proper multipolygon". Your explanation is generally right, but I think that leisure=track can be a line when you want to just mark the shape, because for example you have no aerial photos or their quality is too low to draw the proper outlines (low resolution, trees are hiding details).

[dieterdreist]

sent from a phone

Il giorno 06 ago 2016, alle ore 12:13, mboeringa [email protected] ha scritto:

Simple: line elements only make sense in the context of routing in routing applications, or low zoom display.

a line has a direction, an area hasn't. Rendering aside, this is a general conceptual difference, a reason why a line can make sense

[mboeringa]

because for example you have no aerial photos or their quality is too low to draw the proper outlines (low resolution, trees are hiding details).

a line has a direction, an area hasn't. Rendering aside, this is a general conceptual difference, a reason why a line can make sense

Fair enough, I also have also seen rarely, although this may be less desirable from a rendering point of view, tracks tagged double, both as multipolygon, and with a centre line.

[polarbearing]

Fine, it appears while we were coming from different perspectives, we are in agreement.
Though again, would you see a leisure=track drawn as a multipolygon as implicitly being an area; or requiring explicit area=yes tagging?

[kocio-pl]

I think it's better to change our rendering rule to "line default" (area=yes tag is needed to mark the area), because it makes it possible to draw simple cases and at the same time it prevents map from creating "false stadiums", which is very common side effect now.

Current "area default" (area=yes tag is implied) does not show a simple line, so when you don't know full shape you have to make it up for rendering, which is bad, and when you just draw a circular track, it looks like a pitch and that's bad for me too.

[mboeringa]

Though again, would you see a leisure=track drawn as a multipolygon as implicitly being an area; or requiring explicit area=yes tagging?

Maybe @pnorman or @math1985 can confirm, but I think it likely if it is a true multipolygon, then it will always be processed as such by osm2pgsql, and never end up being a "two line" feature (for outer and inner ring of the track). The latter would of course be highly undesirable. As I understood the issue, it is about simple closed ways, not multipolygons.

[matthijsmelissen]

if it is a true multipolygon, then it will always be processed as such by osm2pgsql, and never end up being a "two line" feature (for outer and inner ring of the track).

This is correct. Multipolygons are always treated as areas.

[kocio-pl]

Just for the record: it's not always multipolygon, sometimes it's just a simple polygon.

[pnorman]

For reference, our current styling is

[feature = 'leisure_track'][zoom >= 10] {
  polygon-fill: @track;
  [zoom >= 15] {
    line-width: 0.5;
    line-color: saturate(darken(@track, 30%), 20%);
  }
  [way_pixels >= 4]  { polygon-gamma: 0.75; }
  [way_pixels >= 64] { polygon-gamma: 0.3;  }
}
...
[feature = 'leisure_track'] {
  text-placement: interior;
  text-fill: darken(@track, 40%);
  ...
}

This is treating it as an area.

It is possible that there was the expectation that it was a line, but this rendering got added because it was being turned into an area by osm2pgsql

[dieterdreist]

sent from a phone

Il giorno 07 ago 2016, alle ore 11:35, Matthijs Melissen [email protected] ha scritto:

if it is a true multipolygon, then it will always be processed as such by osm2pgsql, and never end up being a "two line" feature (for outer and inner ring of the track).

This is correct. Multipolygons are always treated as areas.

otherwise it would be a multiline string, an object we don't have in osm.

[pnorman]

Of the 42.6k relations tagged with leisure=track in my slightly dated DB, 35.1k are closed ways. This means less than I had hoped - a mapper modeling a track as a line will still often draw a closed way.

[kocio-pl]

I think the first problem ("Check if leisure=track should be a polygon tag or not") is already clear. Any news on styling changes?

[matthijsmelissen]

Check if leisure=track should be a polygon tag or not

Checked, it seems that leisure=track should be rendered as line by default. This is already the behaviour of the lua branch, so no change is needed.

[matthijsmelissen]

This is already the behaviour of the lua branch, so no change is needed.

Closing this.

[HolgerJeromin]

I think this should be reopened as

[x] Adjust styling to handle changes

should have no checkmark.

Shouldn't we already have linestring leisure=track coverage for non-closed ways?

https://www.openstreetmap.org/way/144179903 is not rendered on master and lua, so we have no style definition.

[HolgerJeromin]

Please reopen this issue...

[pnorman]

If it's not rendered on master then there's no change

[HolgerJeromin]

Ok, than the correct item is #574
Thanks