path/footway rendering bad to read at z=13/14 #1748
Comments
Unfortunately... it depends. Different mappers have different assumptions.
Please include images. With the servers busy re-rendering, we're not all seeing the same map, and we want to be able to come back and look at this issue later and know what you were looking at at the time. I would include an image, but it hasn't re-rendered for me yet. |
|
I know - that's why i did not write 'mappers generally assume paths to be unpaved'. Still the effect is widespread, many paths without surface tag are unpaved. |
|
In Austria, we follow the convention that all unpaved paths are mapped as highway=path, while paved paths are mapped as highway=footway. That's why we rarely use surface=* tags on highway=path or footway. I'd suggest to make boldness of paths depend on trail_visibility=* instead of surface=*. Bold if trail_visibility=excellent or good. If trail_visibility is not set and surface=paved or asphalt or similar, then trail_visibility=excellent can be assumed. I stumbled across this issue when I saw the new rendering of the following ways which are near to each other: The first way is an important hiking path, while the other is only used by hunters and estate owners. I was surprised that the hiking path is rendered paler and thinner, even though trail_visibility is better and sac_scale is also set. |
|
Another effect of the footway rendering in comparison to the old path rendering is that ways next to streams are less separated than before, like here: It might be a good idea to consider 'fading in' the white casing over a few zoom levels and reduce its strength at z=15/16 or make it thinner and stronger, the latter might also reduce the color intermixing when paths coincide with boundaries. |
|
Same thing @fkv1 just mentioned regarding Austria applies to path/footway convention in Russia and some other ex-USSR countries. |
|
Here is the copy of my comment in the #1713 thread: I strongly oppose this commit. Quotes from the OSM-wiki: The tag highway=footway is used for mapping minor pathways which are used mainly or exclusively by pedestrians. I kindly ask you to revert your commit and discuss the issue with the largest international communities. Otherwise remapping of all outdoor areas will be required. |
Is this any different than it would have been if that had been tagged with highway=footway? The ideal solution if doing the cartography by hand would be to shift the path over slightly for clarity, but that's obviously not an option for us. |
I don't think so. The old path rendering is simply slightly thinner and colorless which both helps keeping the stream visible. |
|
Possible improvement is shown in #1713 (comment), could likewise be applied to tracks, see #1591 (comment). |
|
highway=path on natural=bare_rock is next to impossible to see.
|
This issue is about z13 and z14. For bare rock, see #1765 |
|
Amateur Photoshop test with footway colour changed to (Click to view full size!) Tatra mountains, before: Gdańsk, before: @Adamant36 @kocio-pl What do you think? |
|
@Tomasz-W, I don't have a comment on the color yet, but footways are rendered pretty thin. I noticed in the code that they are rendered with a smaller width etc then track roads. For tracks roads the difference between the longer and shorter dots are easier to tell. Whereas, with footways it just looks like a bunch of tiny dots. So that might be something to look into also. As it makes them harder to see. I don't know if how the dots are rendered has to do with casing or what. |
If you want to increase saturation of footways, I would recommend only doing this for highway=path, not highway=footway. highway=footway in cities is already a problem with current saturation (and no, you cannot judge that by showing images of Z19-20): https://user-images.githubusercontent.com/5439713/47271569-cbfecd00-d57a-11e8-90f7-e7623c635b2d.png from this post: #3467 (comment) Of course, with #3467 silently merged, we won't see the above anymore because the footways and (mountain) paths will no longer render at Z13 once deployed... |
|
The Germany style footways look good. Does anyone else think it might work
to switch to that style for footways?
…On Sun, Nov 18, 2018 at 8:20 PM mboeringa ***@***.***> wrote:
Amateur Photoshop test with footway colour changed to #FF5500. I think it
would resolve the problem without making a mess in cities, but it of course
needs wider tests on different zooms.
If you want to increase saturation of footways, I would recommend only
doing this for *highway=path*, not *highway=footway*.
highway=footway in cities is already a problem with current saturation
(and no, you cannot judge that by showing images of Z19-20):
https://user-images.githubusercontent.com/5439713/47271569-cbfecd00-d57a-11e8-90f7-e7623c635b2d.png
from this post: #3467 (comment)
<#3467 (comment)>
Of course, with #3467 (comment)
<#3467 (comment)>
silently merged, we won't see the above anymore because the footways and
(mountain) paths will no longer render at Z13 once deployed...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1748 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshKiUBzr-EyBfAm6LzEmTzzKqoA4zks5uwUJlgaJpZM4FsIVJ>
.
|
|
@jeisenbe, That might actually be a good solution. I like that its solid fill. Since footway's are usually less like paths. Plus, it would allow us to render paved/unpaved with them later when its implemented in Kosmtik. Would it be applied to sidewalks also and could we go with a yellow/normal outline to designate light/unlit? I think that would be cool. What about paths? |
Imo we have exactly the same rendering for both in this style |
|
sent from a phone
On 18. Nov 2018, at 22:38, Holger Jeromin ***@***.***> wrote:
Imo we have exactly the same rendering for both in this style
paths depend on additional tags, as they can be cycleways, footways, mixed, generic etc.
|
You probably mean "mountain bike trail". Tagging a true cycleway meant for city bikes as highway=path, bicycle=yes would be bad practice IMO, just like tagging a mountain bike trail with highway=cycleway is. |
|
sent from a phone
On 19. Nov 2018, at 07:39, mboeringa ***@***.***> wrote:
Tagging a true cycleway meant for city bikes as highway=path, bicycle=yes would be bad practice IMO, just like tagging a mountain bike trail with highway=cycleway is.
the equivalent for cycleway is path with bicycle=designated
|
|
I agree with the suggestion of @mboeringa to use |
|
I suggest using #FF5500 for paths and the German styles rendering for footways (including sidewalks) so we can show paved/unpaved later when its supported by Kosmtik (plus maybe lit/not lit somehow). |
|
Please notice that images above are just a Photoshop mock-ups uploaded to show basic idea, the same colour applied in real test renderings may give less agressive results, so I would wait for the real ones to rate. |
|
👎 on anything that would treat |
Agree. The difference in semantics between both is just too undefined. |
|
Personally, I said render highway=path different then highway=footway. I didn't say anything about highway=path+foot=yes. The issue wasnt isnt about just paths with foot=yes either. There's no reason they couldnt be rendered the same new way as highway=footway. While other "lesser" highway=path values retain the original rendering. |
|
It would be good if there was a visual difference between how something like a woodsy path through a bunch of bushes versus say a paved sidewalk was rendered though. |
|
Sidewalks are the one type of footpath that could be rendered differently
(eg later zoom level), but it would be best to find a solution that works
for rural and urban areas, if possible.
…On Tue, Nov 20, 2018 at 7:46 PM Adamant36 ***@***.***> wrote:
It would be good if there was a visual difference between how something
like a woodsy path through a bunch of bushes versus say a paved sidewalk
was rendered though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1748 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshOvOYzf8lHoaMPM9ranvspEQaK5eks5uw912gaJpZM4FsIVJ>
.
|
While the exact semantics may be murky on paper, I find these responses a bit surprising, since most mappers do seem capable to distinguish them. Just look at these Overpass Turbo query result: https://overpass-turbo.eu/s/DQI Most highway=path, foot=yes are almost exclusively in rural areas, like forests or mountain paths, except for paths in parks, allotments or cemeteries maybe, while highway=footway is mostly used within urbanized areas and city centers. It is certainly not that mappers in the real world do not make distinction and lump these as being one and the same thing... |
|
sent from a phone
Most highway=path, foot=yes are almost exclusively in rural areas, like forests or mountain paths, except for paths in parks, allotments or cemeteries maybe, while highway=footway is mostly used within urbanized areas and city centers. It is certainly not that mappers in the real world do not make distinction and lump these as being one and the same thing...
the equivalent path tagging for highway=footway would be foot=designated, unless there’s bicycle=designated as well, in which case it is a combined foot and cycleway, either shared (segregated=no) or not.
|
|
Some analogy that comes into mind is that |
|
sent from a phone
On 21. Nov 2018, at 03:26, kocio-pl ***@***.***> wrote:
Some analogy that comes into mind is that highway=path is similar to highway=road, so it might be also rendered as kind of grey line by default to indicate that it's more generic.
it is not similar, highway road is a kind of fixme, path isn’t
|
Agree, but highway=path, foot=designated is rarely used without also bicycle=designated. As you indicate, this combination of tagging seems primarily used in situations where a cycle path and footway are combined and cannot sensibly be separated in OSM as there is usually no physical real world separation as well. Since these "paths" are thus neither highway=footway, nor highway=cycleway, this seems one of the compromises to tag them. A nice example is this Overpass Turbo query from Vienna: Still, in the current styling that doesn't distinguish highway=footway and highway=path, we actually suggest that these highway=path, foot=designated/yes, bicycle=designated/yes are equivalent to highway=footway, while on a properly tagged highway=footway, you should theoretically never encounter a bicycle. This is a significant difference not obvious in the current styling. |
|
Am Mi., 21. Nov. 2018 um 10:29 Uhr schrieb mboeringa <
[email protected]>:
the equivalent path tagging for highway=footway would be foot=designated,
unless there’s bicycle=designated as well, in which case it is a combined
foot and cycleway, either shared (segregated=no) or not.
Agree, but *highway=footway*, *foot=designated* is rarely used without
also *bicycle=designated*.
maybe you meant highway=path? I wouldn't consider a way with foot and
bicycle designated a "footway", (maybe in the UK they would?)
|
@dieterdreist |
|
I would try with some dotted lines for paths (orange as footways or dark red like they are in JOSM). By the way I consider different rendering of footways/ cycleways depending on surface=* value as totally useless and unnecessary map complicating. It's not intuitive at all (and I don't see any good way to show this difference), and I'm sure that most of map users have no idea why some parts of footways/ cycleways are rendered e.g. as dahed lines and some another ones by dashed lines + dots. |
I didn't say they are identical, just similar. For roads it's a hidden assumption that there's no generic road and you can always find a proper classification (which might be not true), so this is for unknown roads, but a path seems to be also "unknown" and generic, yet nobody expects you should classify it as something specific (as a footway, bridleway, cycleway etc.). For both generic and unknown ways grey seems to be pretty intuitive for me (I say only about default tag, with nothing added to make it more specific). |
|
cycleway and footway had specificities by countries.... In France cycleway dont accept foot if traffic sign is only for bicycle and if there isn't segregated pannel In addition you can have reversed situation with footway because this is a sidewalk or crossing with signalisation for foot only and implicit value is bicycle=no By default certains country add implicit value yes or designated but this is not a general case. So there is not "the general case". for me there is no deference between values designated,official and yes for the display because access is accepted for all cases. The reversed situations are no or unknown. The last is overloading by implicit comportment by country path is a group of type without vehicule you can have a norrow way it accept vehicule quad or motorcycle for exemples and in this case this is a track or service (service=norrow) road So for a good representation use cases are only the solution. We have also a particularity in France "Voies Vertes" |
With the unification in #1713 the problem of badly readable rendering at z=13/14 is much more pressing. This was originally subject in #668 and improved but not really fixed in #747. See for example around here:
http://www.openstreetmap.org/#map=13/47.9992/7.8278
where at those zooms there is just a lot of mostly meaningless red noise all over.
This is difficult to fix, you'd need selective rendering based on feature density which is difficult to achieve without getting counter-intuitive. However in this case even a relatively crude solution is probably an improvement.
Another problem of the path rendering change is that it is now assumed to be paved by default which is not the assumption generally made by mappers. As a result important paths are often rendered weaker since they have a specific unpaved surface tag while less important ones without surface tag are rendered strongly.
The text was updated successfully, but these errors were encountered: