path/footway rendering bad to read at z=13/14

[imagico]

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.

[pnorman]

which is not the assumption generally made by mappers

Unfortunately... it depends. Different mappers have different assumptions.

where at those zooms there is just a lot of mostly meaningless red noise all over.

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.

[imagico]

Unfortunately... it depends. Different mappers have different assumptions.

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.

[fkv1]

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: http://www.openstreetmap.org/way/115357612 http://www.openstreetmap.org/way/360315514

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.

[imagico]

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.

[BushmanK]

Same thing @fkv1 just mentioned regarding Austria applies to path/footway convention in Russia and some other ex-USSR countries.

[vvoovv]

Here is the copy of my comment in the #1713 thread:

I strongly oppose this commit. path and footway are totally different entiites according to OSM-wiki:

Quotes from the OSM-wiki: highway=path is a generic path, either multi-use or unspecified usage, open to all non-motorized vehicles. The path may have any type of surface. This includes walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails as well as combinations of the above.

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.

[pnorman]

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:

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.

[imagico]

Is this any different than it would have been if that had been tagged with highway=footway?

I don't think so. The old path rendering is simply slightly thinner and colorless which both helps keeping the stream visible.

[imagico]

Possible improvement is shown in https://github.com/gravitystorm/openstreetmap-carto/pull/1713#issuecomment-131612727, could likewise be applied to tracks, see https://github.com/gravitystorm/openstreetmap-carto/issues/1591#issuecomment-131622631.

[Reitstoen]

highway=path on natural=bare_rock is next to impossible to see. http://www.openstreetmap.org/#map=15/-3.0795/37.3805

[pnorman]

highway=path on natural=bare_rock is next to impossible to see. http://www.openstreetmap.org/#map=15/-3.0795/37.3805

This issue is about z13 and z14.

For bare rock, see #1765

[Tomasz-W]

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.

(Click to view full size!)

Tatra mountains, before: Tatra mountains, after:

Gdańsk, before: Gdańsk, after:

@Adamant36 @kocio-pl What do you think?

[Adamant36]

@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.

[mboeringa]

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: https://github.com/gravitystorm/openstreetmap-carto/pull/3467#issuecomment-431701959

Of course, with https://github.com/gravitystorm/openstreetmap-carto/pull/3467 silently merged, we won't see the above anymore because the footways and (mountain) paths will no longer render at Z13 once deployed...

[jeisenbe]

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 notifications@github.com 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) https://github.com/gravitystorm/openstreetmap-carto/pull/3467#issuecomment-431701959

Of course, with #3467 (comment) https://github.com/gravitystorm/openstreetmap-carto/pull/3467#issuecomment-431701959 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 https://github.com/gravitystorm/openstreetmap-carto/issues/1748#issuecomment-439685160, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshKiUBzr-EyBfAm6LzEmTzzKqoA4zks5uwUJlgaJpZM4FsIVJ .

[Adamant36]

@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?

[HolgerJeromin]

doing this for highway=path, not highway=footway

Imo we have exactly the same rendering for both in this style

[dieterdreist]

sent from a phone

On 18. Nov 2018, at 22:38, Holger Jeromin notifications@github.com 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.

[mboeringa]

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.

[dieterdreist]

sent from a phone

On 19. Nov 2018, at 07:39, mboeringa notifications@github.com 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

[jragusa]

I agree with the suggestion of @mboeringa to use #FF5500 restrict only for highway=path. IMO, it's a bit too saturated in cities.

[Adamant36]

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).

[Tomasz-W]

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.

[pnorman]

👎 on anything that would treat highway=path foot=yes different from highway=footway.

[mmelissen]

👎 on anything that would treat highway=path foot=yes different from highway=footway.

Agree. The difference in semantics between both is just too undefined.

[Adamant36]

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.

[Adamant36]

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.

[jeisenbe]

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 notifications@github.com 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 https://github.com/gravitystorm/openstreetmap-carto/issues/1748#issuecomment-440228518, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshOvOYzf8lHoaMPM9ranvspEQaK5eks5uw912gaJpZM4FsIVJ .

[mboeringa]

👎 on anything that would treat highway=path foot=yes different from highway=footway.

Agree. The difference in semantics between both is just too undefined.

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 https://overpass-turbo.eu/s/DQK https://overpass-turbo.eu/s/DQL

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...

[dieterdreist]

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.

[kocio-pl]

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.

[dieterdreist]

sent from a phone

On 21. Nov 2018, at 03:26, kocio-pl notifications@github.com 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

[mboeringa]

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=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: https://overpass-turbo.eu/s/DRe

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.

[dieterdreist]

Am Mi., 21. Nov. 2018 um 10:29 Uhr schrieb mboeringa < notifications@github.com>:

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?)

[mboeringa]

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 That was indeed a typo, I already corrected it in the above post.

[Tomasz-W]

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.

[kocio-pl]

it is not similar, highway road is a kind of fixme, path isn’t

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).

[geostonemarten]

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 so cycleway is by default with foot=no

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 we can add permissive access or designated access for bicycle with signalisation but crossing are on zebra and zebra is only a foot crossing. implicitly if there is no crossing for bicycle you need legally dismont to your bicycle for crossing but there is a permisive legal accept to don't dismout. "Eventually though" there is an accident...

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 track accept vehicle

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. Two pages to read https://wiki.openstreetmap.org/wiki/Highway:International_equivalence https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

We have also a particularity in France "Voies Vertes" https://wiki.openstreetmap.org/wiki/FR:Bicycle#Voies_vertes