Ziplines should not be rendered at low zoom levels

[freddie1729]

Expected behavior

Ziplines should only show up when zoomed in enough.

Actual behavior

At low zoom they just appear as a black smudge and clutter the map. They should not show up at all until zoomed in a lot.

Links and screenshots illustrating the problem

In my opinion they should not be shown at all in these screenshots.

[HolgerJeromin]

There are many in this area (perhaps this is part of this problem).
Link to one of them:
https://www.openstreetmap.org/way/830967029

[freddie1729]

Here's an example of where there's just one and it still appears when zoomed quite far out. https://www.openstreetmap.org/way/896750451

[pitdicker]

I have been looking into changing this. A problem is that ziplines can both recreational, or part of the infrastructure. See https://wiki.openstreetmap.org/wiki/Tag:aerialway%3Dzip_line and https://en.wikipedia.org/wiki/Zip_line. An example of what I think counts as the latter one is https://www.openstreetmap.org/#map=13/5.9208/-75.4344.

Having them appear at zoom level 12 seems about right when the zipline is used as infrastructure. For leisure it should propably start rendering around zoom 16. How to know the difference?
leisure=playground or sport=climbing_adventure are recommended tagging combinations. But I didn't see them in the cases that I looked at. And the y don't really seem appropriate for commercial ziplines for fun.

Is this solvable with the current or future tags?

[dch0ph]

Is a possible solution to filter on the way length as:
ST_Length(way)/NULLIF(!scale_denominator!*0.001*0.28,0) AS way_pixels
?

This might be useful in general, e.g. to filter out very short lengths of cliff, which similarly look like random pixels.

[pnorman]

Because ways can be split, it's not meaningful to filter by length.

[dch0ph]

I guess this is a potentially an issue with linear features in contrast to closed ones.

I have used this in my own fork to determine the text size for natural=valley [at Z11]:

There's no reason why natural=valley should be split, and semantically you would want one object for one feature.

I can see the problem if a zipline were split into separate ways, where a section might suddenly disappear, but
(a) I can't see a reason to split such ways, e.g. to have different tags on different sections. [The road network is the opposite extreme, where improving information involves splitting ways.]
(b) we're talking about filtering out unparseable rubbish of a few pixels - a gap wouldn't be seen.

[imagico]

The solution here is to come up with a suitable choice for a starting zoom level for the feature in question. So far all types of aerialways start at z12 - which is evidently not an ideal choice.

We definitely do not want to impose constraints on mappers how to map things purely because those would be convenient for us.

we're talking about filtering out unparseable rubbish of a few pixels - a gap wouldn't be seen.

Incidentally, someone thought the same about water polygons in 2017 (#2952) and collectively it took us more than two years (until #4060) to realize and accept that this was an illusion.

That neither means we have to accept the rendering issues pointed out here nor that analyzing the geometric extent of the aerialways categorically cannot be used to derive criteria for which to show and which not. But you have to go the extra mile to develop a solid approach (and that might be computationally somewhat expensive when you want to go with analyzing the geometries), there is no simple way here.

[dch0ph]

Filtering on ways that are part of networks, like roads and waterways, is clearly a Bad Idea. I don't think that's the question.

I agree there isn't a general answer, but there is a difference between, say, natural=valley which is semantically a continuous way and a network.

But there may be a simpler specific solution. The rendering of zip_wire is not scaling gracefully with feature size. At small sizes, the key 1 pixel line is drowned by the 4 pixel "decoration" perpendicular to it:

      line/line-width: 1;
      dash/line-width: 4;
      dash/line-dasharray: 1,30;

so you start with a set of 4 pixels of decoration which doesn't smoothly evolve into the key linear feature. The Alexandra Palace example involves a bunch of zipwires in a small area, and so is an "unparseable" mess.

I think you can get mapnik to start dashed lines on the gap e.g. dash/line-gasharray: 15,1,15;? This would scale better, as you would get 15 pixels of line before the first decoration.

[dch0ph]

Current rendering of Alexandra Park area above. This is from a PDF rather than bitmap render, which makes the issues clearer:
Z12:

Z14:

(still unparseable)
Z16:

At last!

So, I think there are two problems with the evolution with zoom: too great a contrast between "wire" and "decoration", and "decoration" too prominent at low zoom. Changing the starting zoom will only change when these issues arise.

Testing alternative rendering:
Z12

Z14

Z16

This uses a common intermediate grey, and a 0,10,1,10 dash pattern. The linewidth is fixed at 1 (as currently). Arguably this should be scaled at low zoom (width too big at Z12).

For consistency, this would entrain a merging of grey scales for aerialway=cable_car (and friends) [currently #888 and black], and aerialway=goods [currently #888 and #777] (is there a logic to these contrast patterns?). So further discussion / consensus needed.