-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poor result of rendering areas with many footways in zoom level 13 #211
Comments
I agree. |
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). |
Note that mixed cycleway/footways are sometimes tagged as [highway=path; bicycle=designated; foot=designated]. |
@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. |
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 |
Sure, but look at the upper-right corner of the map. Do we really want * On Wed, Oct 23, 2013 at 2:55 AM, Bulwersator [email protected]:
|
I reported this ticket and upper-right corner of the map is linked in initial report :). |
Okay, sorry, I guess I didn't realize that both examples were pretty much On Wed, Oct 23, 2013 at 11:16 AM, Bulwersator [email protected]:
|
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. |
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. |
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 |
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. |
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. Perhaps these footways, if rendered, should not have bridge casings at these zoom levels. |
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. |
@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. |
- Make paths and tracks less visible on z13/z14, by making them narrower and remove the casing at these zoomlevels. This declutters in high-density environments, while at the same keeping the paths and tracks visible in low-density environments. - Hide private paths and tracks on z13/z14. - Define path/track widths with variables. - Make widths of path/track bridges and tunnels more consistent. - Add rendering for steps in tunnels. - Add background (glow) to steps, just like footways. This solves the following issues: * gravitystorm#211 (Poor result of rendering areas with many footways in zoom level 13) * gravitystorm#620 (Tracks too dominant on z13) * Trac 1508: don't render tracks of high tracktype at low zoom (-> wontfix) * Trac 3788: Don't render highway=track, access=private at z13&14 * Trac 4015: Rendering of highway=path with access=no is inconsistent * gravitystorm#634: private footways should not be rendered up to z13
- Make paths and tracks less visible on z13/z14, by making them narrower and remove the casing at these zoomlevels. This declutters in high-density environments, while at the same keeping the paths and tracks visible in low-density environments. - Hide private paths and tracks on z13/z14. - Define path/track widths with variables. - Make widths of path/track bridges and tunnels more consistent. - Add rendering for steps in tunnels. - Add background (glow) to steps, just like footways. This solves the following issues: * gravitystorm#211 (Poor result of rendering areas with many footways in zoom level 13) * gravitystorm#620 (Tracks too dominant on z13) * Trac 1508: don't render tracks of high tracktype at low zoom (-> wontfix) * Trac 3788: Don't render highway=track, access=private at z13&14 * Trac 4015: Rendering of highway=path with access=no is inconsistent * gravitystorm#634: private footways should not be rendered up to z13
Closed by #747. |
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).
The text was updated successfully, but these errors were encountered: