footway and path rendering and tagging

[shrddr]

Default osm rendering style recently changed highway=path from black dashes to red dots (gravitystorm/openstreetmap-carto#1713). Should probably do the same in iD.

There is now no visible difference in rendering between highway=footway and highway=path. Distinct rendering (thinner line) is now only achieved by explicitly entering surface=unpaved. I suggest a new feature shortcut for quick access: "Unpaved Footpath", which means highway=footway + surface=unpaved.

Alternatively, the existing "Path" shortcut should be changed to include surface=unpaved by default. As stated in wiki, it includes "walking and hiking trails, bike trails and paths, horse and stock trails, mountain bike trails" all of which are usually unpaved.

[pnorman]

Alternatively, the existing "Path" shortcut should be changed to include surface=unpaved by default

This is probably a bad idea, as path implies different things to different people.

[bhousel]

I did recently change the rendering of path to make it more like footway: #2327 (comment)

#2564 covers rendering paved and unpaved roads differently, and if you look at the track in the comment linked to above, I think that's how I plan to do it going forward - a bumpy casing can indicate that a way is unpaved (or is implied to be unpaved, which tracks are).

Like @pnorman said, it's not a good idea for iD to automatically add an explicit surface tag - instead we will continue to show a surface field in the sidebar so that users can choose the surface.

Also, I will probably change the highway colors to match whatever openstreetmap-carto is doing.

[pnorman]

(or is implied to be unpaved, which tracks are).

tracktype1 is generally often assumed to be paved in absence of other information

Like @pnorman said, it's not a good idea for iD to automatically add an explicit surface tag - instead we will continue to show a surface field in the sidebar so that users can choose the surface.

+1

[SHARCRASH]

Is there an important reason why the rendering of Path has been changed to look alike the Footway? In my opinion, each one suggest clearly 2 different types of ways, by their whole definition and utility. But since the change has been made, it destroyed the ability to recognize either by its looks and definition for a certain use, unless the area has been plotted. In extra, it forces mappers to insert more work directly and I've seen that not many mappers do that.

In my opinion, it is primordial that both should be directly distinguishable. By the simple fact of adding a Footway without any extra tagging, you know by definition the following (origin, aspect, use & presence) :

• it's a man made way, most often found in urban areas
• most often it is shaped as a flat surface (thinking of gravels if not) with a certain transformed material, easily recognizable and that can be easily walked or ridden
• usually for pedestrians, easy walking, wheelchairs, but if not payed attention by a official signalization can be borrowed by urban bicycles, kids bicycling or on rollers... etc.
• it's a kind of permanent structure until human intervention

For Path :

• it's the alteration of the surface of nature by wear
• surface can be of anything natural, or easily covered by natural elements (grass growing, overflowed by leaves...) and most often irregular, so not necessarily directly recognizable/visible
• it's utility can be hiking, sports (trail running, mountain biking, horse riding...), exploration or more specifically can be plotted for reference of animal presence (not sure though mappers plot for this utility, i'd not recommend since animals need space to survive too).
• existence is totally dependent of it's frequency of use whereas it's human or animal.

It's a pity that so much isn't anymore directly differentiated.

Short comment on the Track, no real issue since if you insert the key Tracktype, it is differentiated accordingly. Not sure it is the perfect solution, but nice enough as it is set now, even only with a Track key.

PS: i have many ideas in terms of "logic of rendering" for easy looking that i kept for myself. If you are interested, i can suggest and even propose help on rendering in terms of illustrating, I'm proficient in graphic design.

[bhousel]

Is there an important reason why the rendering of Path has been changed to look alike the Footway?

Discussed briefly here on #2327, and more extensively in osm-carto github and mailinglists. Main reason for iD was just that our path rendering was so thin that they were hard to see on certain backgrounds, so it made sense to just bring them into the bridalway/cycleway/footway family. Some users in iD were picking footway just so they could see it.

since the change has been made, it destroyed the ability to recognize either by its looks and definition

They are slightly different colors, but I should probably make the colors a little more different.

By the simple fact of adding a Footway without any extra tagging, you know by definition the following...

Unfortunately, no.. None of those things that you listed are known for sure... path vs footway was just discussed extensively on the tagging mailing list, and around the world people use the tags differently. I don't assume anything about these tags anymore.

Short comment on the Track, no real issue since if you insert the key Tracktype, it is differentiated accordingly.

Yes we make tracktype available for the Track preset.

PS: i have many ideas in terms of "logic of rendering" for easy looking that i kept for myself. If you are interested, i can suggest and even propose help on rendering in terms of illustrating, I'm proficient in graphic design.

Yes definitely! First read through our open issues, because we do have a lot of open rendering/design issues - your ideas might be in there somewhere already. Anything that makes it easier for users to make good edits is a helpful suggestion.

[SHARCRASH]

Agreed that around the world people have different interpretations. According all the descriptions in OSM's Wiki I think that my interpretations fit those tags if they don't have extra detailing keys.

Coming back more specifically to our rendering topic, i think that every different element that has been created apart should have its own rendering, since in terms of data there is a use to distinguish them, so should it be in terms of visual. So a significant difference at least but indeed a drastic difference may introduce bad interpretations. We are falling again in the logics of graphics interpretation. At the present time, they are indistinguishable and I'm thinking about all those third party non mapping users.

[matkoniecz]

Like @pnorman said, it's not a good idea for iD to automatically add an explicit surface tag - instead we will continue to show a surface field in the sidebar so that users can choose the surface.

Maybe it would be a good idea to introduce entries "paved path" and "unpaved path" in addition to general "path".

[SHARCRASH]

matkoniecz said:
Maybe it would be a good idea to introduce entries "paved path" and "unpaved path" in addition to general "path".

Paved/unpaved is managed with the Surface key, no need to add redundant tags.

[matkoniecz]

Paved/unpaved is managed with the Surface key, no need to add redundant tags.

I am suggesting entries to select in iD, not a new tags ("unpaved path" would result in using tags [highway=path, surface=unpaved]).

[SHARCRASH]

Oh i see, sorry. OK! :)

[winternet-studio]

I'm also confused about the new rendering of paths. I understand the old paths might have been too thin for some but it's a huge leap to rendering them so wide as they are now. It doesn't make sense that they are now wider than a track. It must be possible to render them as narrower than a track but still clearly visible.

[bhousel]

@winternet-studio, what you are seeing may be an optical illusion. In fact track and path are defined in map.css to have exactly the same thickness (along with every other kind of minor road).

Is there an example where the new rendering is making it difficult to edit?

[winternet-studio]

I see, but that doesn't mitigate my point. Perception is what matters, not technical correctness. And actually, it is only because of the orange extrudes that it is same width where a path has the same width constantly - so you could argue that they are not the same width. It would be better to switch them around - or just make a path a few pixels narrower. With current rendering you could just as easily have new users make mistake because they want a track to show up wider in the editor than a path.

(I'm editing a lot of trails in the forest and they are always narrower than a track - but maybe that is just my scenario, don't know of other scenarios is playing in on the overall decision)

[bhousel]

Looks like this now, I think the brighter track casing helps make it appear wider: