Poor result of rendering areas with many footways in zoom level 13

[matkoniecz]

Result is an unreadable mess - see http://www.openstreetmap.org/?mlat=50.0755&mlon=19.9532#map=13/50.0755/19.9532 for an example.

With current rendering results resembles colony of ants rather than a map. Maybe rendering it more as lines rather than dots (or flattened dots to keep compatibility with other zoom levels) would help?

Or maybe drop footways in this zoom level (maybe keep cycleways, maybe keep footways in less densely tagged areas).

[cymerio]

I agree.
Footways are very commonly mapped in parks. Right now parks look like areas filled with red dots and nothing more. They should look mainly green, plus some details in other colors, but mainly green.

[compdude]

I think footways should not be rendered at such a high zoom like that. Same with paths. But cycleways should still render at this zoom (13).

[matkoniecz]

Note that mixed cycleway/footways are sometimes tagged as [highway=path; bicycle=designated; foot=designated].

[compdude]

@Bulwersator, good point. But I wouldn't care if a path that had the bicycle=designated tag didn't render at the same zoom as a cycleway.

[matkoniecz]

example of area where footways should be rendered at zoom level 13: http://www.openstreetmap.org/?mlat=50.0505&mlon=19.8417#map=13/50.0505/19.8417

[compdude]

Sure, but look at the upper-right corner of the map. Do we really want *
those* rendering at that low of a zoom? I wouldn't mind having to zoom in a
bit more to see those footways.

On Wed, Oct 23, 2013 at 2:55 AM, Bulwersator notifications@github.comwrote:

example of area where footways should be rendered at zoom level 13:
http://www.openstreetmap.org/?mlat=50.0505&mlon=19.8417#map=13/50.0505/19.8417

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/211#issuecomment-26892761
.

[matkoniecz]

@compdude

I reported this ticket and upper-right corner of the map is linked in initial report :).

[compdude]

Okay, sorry, I guess I didn't realize that both examples were pretty much
the same area.

On Wed, Oct 23, 2013 at 11:16 AM, Bulwersator notifications@github.comwrote:

@compdude https://github.com/compdude

I reported this ticket and upper-right corner of the map is linked in
initial report :).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/211#issuecomment-26929646
.

[gravitystorm]

I would love to have differential rendering based on "prominence" - so that when there's one footpath across a mountain at z13 it shows up, and at the same time, it doesn't show lots of paths all clustered together in a graveyard. Similar considerations apply for roads too.

I don't have any idea of a working approach - whether based on density, network analysis or something else. So while I'm closing this ticket it doesn't mean that it's not valid, it just means that there's no feasible solution. When someone makes their own experiments and find something that works, or new features are added to the tools, then lets look at it then.

[matkoniecz]

@gravitystorm

I am aware that there is no ideal solution, but I think that currently dropping display of footways at zoom level 13 is better than waiting for a perfect fix.

[pnorman]

I would love to have differential rendering based on "prominence" - so that when there's one footpath across a mountain at z13 it shows up, and at the same time, it doesn't show lots of paths all clustered together in a graveyard. Similar considerations apply for roads too.

I think there's two separate issues here. One is the need for density-based rendering, which is beyond what we can do within osm-carto, and the other is that the current highway=footway style looks worse at low zooms than other possible choices, like a solid line.

[matthijsmelissen]

Reopened: I agree with @pnorman that we can improve the rendering.

I'm not even sure whether I agree with @mkoniecz that footways should be rendered on z13 in http://www.openstreetmap.org/?mlat=50.0505&mlon=19.8417#map=13/50.0505/19.8417.

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/4007.

[matthijsmelissen]

See also https://trac.openstreetmap.org/ticket/3436.

[matthijsmelissen]

Also tangentially related:
https://trac.openstreetmap.org/ticket/4015
https://trac.openstreetmap.org/ticket/3788
https://trac.openstreetmap.org/ticket/4679
https://trac.openstreetmap.org/ticket/1508

[pnorman]

I had a look at some local areas with a mix of footways, tracks, paths, and cycleways.

I'm not certain that appearing at z13 is unreasonable

The problem is when adjacent footways are about as far apart as the length of dashes, then it is impossible to see them as two distinct lines. This is approximately 50m apart.

Even before this, it becomes difficult to make sense of the footways. In this example, they're generally 100m-200m apart, but I find it difficult to pick out useful information other than the mere presence of footways.

Cycleways are essentially the same as footways, just a different colour. The North Shore mountains are covered with bike paths, but I find it difficult to piece together what's going where here

[hlaw]

Without access to network analysis, filtering by length might give a good compromise to remove the "noise". Perhaps we could drop rendering of those footways, cycleways, steps etc not longer than say 2-3 dashes at each zoom level. This would not help with the graveyard grids, and might break apart long prominent footways (if they are made up of shorter sections), but undesirable urban red dots.

In this relation, footways that are bridges are even worse at zoom levels such as 14-15.
http://a.tile.openstreetmap.org/14/13387/7151.png

Perhaps these footways, if rendered, should not have bridge casings at these zoom levels.

[matkoniecz]

@hlaw

This is terrible idea, as OSM data model requires segmenting way on any change of tags (surface, lit etc) or attached relations.

Also, really long way may cross itself multiple times and be rendered as messy dotted area.

[hlaw]

@mkoniecz sure, indeed footpaths would be segmented for common reasons such as branching. If the length threshold for retaining osm ways is kept low (to a few dots), a more prominent section of footpath would completely disappear only if it needs to switch tags for every few dots at the zoom level concerned (or broken apart into osm ways in such manner for whatever reasons). Without better analysis available, filtering by length is just a heuristic for consideration in striking a middle ground between complete removal as suggested, or the status quo in retaining all footpaths.

[matthijsmelissen]

Closed by #747.