Skip to content
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

stop displaying highway=footway and highway=path differently #1698

Closed
matkoniecz opened this issue Jul 28, 2015 · 74 comments

Comments

Projects
None yet
@matkoniecz
Copy link
Collaborator

commented Jul 28, 2015

In theory highway=path may be nearly anything, in practise it is used mainly as

(1) equivalent of highway=footway; footway=unpaved
(2) equivalent of highway=footway
(3) with both foot=designated and bicycle=designated, interpreted as combined footway and cycleway (may or may not be segregated)
(4) to indicate that it used by pedestrians but this feature was not constructed with intention to be used by pedestrians
(5) with bicycle=designated, interpreted as equivalent of highway=cycleway
(6) rare features like mountain bike trails

Overall difference between highway=path and highway=footway is minor compared to other features and huge difference in rendering is not justified.

Maybe it would be a good idea to render for example mountain bike trails differently but highway=path/footway difference is not allowing to detect cases like that.

Differentiation of styling would be better based on surface tag what would encourage proper mapping rather than selecting tag that renders like something paved/unpaved as it is done currently.

Such change would basically mean that attempt to use highway=path for highly varied features is considered as failed and it encouraged treating it as duplicate of highway=footway.

I tested my region (with highway=path typically used in tagging for renderer to indicate surface=unpaved) with unified rendering (with highway=path/footway using current style for path and later using current footway style for both). Overall, I was surprised by limited negative effect and how noticeable was improvement due to stopping of representing two nearly the same things using the same style.

I think that unified to highway=path map was prettier and unified to highway=footway style it was more readable.

Code is available at https://github.com/matkoniecz/openstreetmap-carto/tree/to-footway and https://github.com/matkoniecz/openstreetmap-carto/tree/to-path

examples of before/after

to footway style:

https://cloud.githubusercontent.com/assets/899988/8944927/b5ffd00c-3583-11e5-81a6-763221f43786.png
https://cloud.githubusercontent.com/assets/899988/8944929/b6031c6c-3583-11e5-8ec7-704b6e51e39f.png
https://cloud.githubusercontent.com/assets/899988/8944928/b6023acc-3583-11e5-8bb7-46880d5adc1a.png
https://cloud.githubusercontent.com/assets/899988/8944930/b605ec62-3583-11e5-8dc7-78df3515619f.png

to path style:

https://cloud.githubusercontent.com/assets/899988/8944942/c3b777a4-3583-11e5-8670-d6d1bf57639e.png
https://cloud.githubusercontent.com/assets/899988/8944945/c3f81b92-3583-11e5-8afd-b5f7ffd98eeb.png
https://cloud.githubusercontent.com/assets/899988/8944944/c3f80d1e-3583-11e5-8d8b-b1b8c3ea2609.png
https://cloud.githubusercontent.com/assets/899988/8944946/c3f919b6-3583-11e5-83ea-1825a928840b.png

It is next part of road redesign that I think may be considered independently.

This idea was proposed in https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35389 (section "highway=path, highway=footway problems") and discussed a bit in comments.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Jul 28, 2015

I think you're right. I like unifying to highway=footway by default to match steps (and when marked as paved) and showing as current path when unpaved.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 28, 2015

In case of unifying to highway=path it should be quite easy to find fitting step colours. Maybe even use the same as in rejected footway styling - (steps are near intermittent stream in top-right region)

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Jul 29, 2015

I'd also be in favour of normalizing highway=path into highway=footway or highway=cycleway depending on access/etc.

@systemed does this, and he also tries to derive surface information based on other tags and rural vs urban. I'm not sure we'd want to go quite that far.

@systemed

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2015

Indeed - I use Lua to normalise (for example) highway=path into other highway values depending on access tags, or to highway=footway where there are no access tags present.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2015

I'd also be in favour of normalizing highway=path into highway=footway or highway=cycleway depending on access

It is already done currently for some cases (on bicycle=designated, horse=designated or foot=designated). Maybe it can be done also on bicycle=yes, horse=yes, foot=yes (also to cycleway/bridleway/footway).

Probably it may be possibly to detect highway=path for weird transport types and stop displaying this type of highway=path (for example http://www.openstreetmap.org/way/80377055) Maybe ["highway"="path"]["foot"="no"]["bicycle"!="yes"]["bicycle"!="designated"]["horse"!="yes"]["horse"!="designated"]["access"!="no"] would work (http://overpass-turbo.eu/s/aDQ).

@systemed

normalise (for example) highway=path into other highway values

Can you link to this code?

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Jul 29, 2015

normalise (for example) highway=path into other highway values
Can you link to this code?

He's doing it in Lua and we'd be doing it in SQL, also he's handling a bunch of other complications we aren't.

@systemed

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2015

Yep, and it wouldn't be particularly transplantable in this case - I actually normalise to several different pseudo-tags which combine access and surface. But essentially the approach is that first I boil down relevant access tags for bikes into yes/no:

{ permissive='yes', designated='yes', official='yes', private='no', agricultural='no', forestry='no', delivery='no', restricted='no', ['true']='yes', ['1']='yes', ['false']='no', ['0']='no' }

and then create a new highway value based on this and the current highway value together.

@jojo4u

This comment has been minimized.

Copy link

commented Jul 29, 2015

I think most agreed on:

  • render paved footway and path as current footway
  • render unpaved footway and path as current path
  • render bicycle=designated as current cycleway
@jojo4u

This comment has been minimized.

Copy link

commented Jul 29, 2015

It is already done currently for some cases (on bicycle=designated, horse=designated or foot=designated). Maybe it can be done also on bicycle=yes, horse=yes, foot=yes (also to cycleway/bridleway/footway).

I don't get this. What is gained by detecting horse=designated (-> use bridleway!) and foot=designated?

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 29, 2015

According to http://taginfo.openstreetmap.org/tags/highway=path#combinations there are over 285k highway=path with foot=designated. There are just 3k ways with horse=designated.

I admit that I see no good reason to use highway=path; horse=designated and for foot=designated (except combining it with bicycle=designated - what anyway would result in rendering it as cycleway). Only highway=path; bicycle=designated; foot=designated makes some sense - and only because this variant is widely recommended and supported.

@RobJN

This comment has been minimized.

Copy link

commented Jul 31, 2015

Generally I support this as the footway vs path issue is frustrating. I do however do a lot of rural mapping and I come across many areas that have a clear "main" path and "lesser" paths. Both may be unpaved but the "main" path will be easier to follow (well worn so the route is easy to see, less overhanging branches so easy to pass).

I'd like to know your view on rendering these differently. We render roads differently based on motorway/trunk/primary/etc so why not paths? When using a map to navigate rural areas an indication of the quality of the path would help. I appreciate that this may need a new tagging scheme as surface=* isn't really sufficient when both are unpaved! Maybe a start would be to render those paths that are part of a relation differently?

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Jul 31, 2015

I come across many areas that have a clear "main" path and "lesser" paths.

I'd like to know your view on rendering these differently

Interesting idea, but not really related to this issue, as highway=path vs highway=footway doesn't distinguish what you're talking about. If you think the information to make this distinction is available through other tagging, can you open a new issue for it?

@Gazer75

This comment has been minimized.

Copy link

commented Aug 2, 2015

Please do not combine these! Path and footway is very different here in Norway.
A path is a natural thing from people walking the same path over and over.
Footway is a constructed path that is not signed as a foot-/cycleway

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Aug 2, 2015

@Gazer75 The highway=footway/path distinction doesn't capture that difference well, though. In the UK, many footways resulting from people walking the same path over and over are tagged highway=footway.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Aug 2, 2015

BTW: there is now a proposition on Tagging list to make footway definition more clear.

@ghost

This comment has been minimized.

Copy link

commented Aug 2, 2015

When using a map to navigate rural areas an indication of the quality of the path would help. I appreciate that this may need a new tagging scheme as surface=* isn't really sufficient when both are unpaved!

Relevant keys may include trail_visibility, smoothness, sac_scale (hiking) and mtb:scale (mountain-biking).

@dieterdreist

This comment has been minimized.

Copy link

commented Aug 2, 2015

Am 02.08.2015 um 17:58 schrieb Gazer75 notifications@github.com:

A path is a natural thing from people walking the same path over and over.

you can add informal=yes to these (i.e. cases that are not built on purpose)

@Gazer75

This comment has been minimized.

Copy link

commented Aug 3, 2015

Well I just fear doing this will alienate all the trekking mappers we have in Norway. Probably half our mappers are doing this work in addition to other things.
If there is no visual difference they might just give up. To have trekking paths be visually the same as a footway in a residential area in the city or ways through the cemetery or park area is just wrong imo.

https://www.openstreetmap.org/#map=13/59.9615/10.7184 is a good example.
All the paths up north will show up as red dots like in the cemetery and park areas in the city.

@math1985 There have been the same problem in Norway as well, but I think the mappers have been fixing this. Wrong tags on stuff is nothing new in all aspects of osm.

@dieterdreist adding more tags is just making things unnecessarily complicated. This is also a visual issue, not about tags. Doesn't matter what tags you add if the renderer is treating path and footway as the same.

@jojo4u

This comment has been minimized.

Copy link

commented Aug 3, 2015

@Gazer75 in your example two paths I checked are tagged as unsurfaced. The cementery ways are footways without surface. Since the default is paved there will be a distinction.

A path is a natural thing from people walking the same path over and over.

That's an over-specific interpretation of path.

@Gazer75

This comment has been minimized.

Copy link

commented Aug 3, 2015

Again the surface tag will have no bearing on the rendering if footway and path is to be rendered the same way.

The interpretation work for us here in Norway so I see no reason to change that.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 4, 2015

@Gazer75

surface tag will have no bearing on the rendering if footway and path is to be rendered the same way.

#1713 is proposing to unify styling for highway=path and highway=footway and render surface tag.

@Gazer75

This comment has been minimized.

Copy link

commented Aug 18, 2015

As I was afraid of... some of the more active mappers in Norway are quite unhappy about this change.

I have to admit Im getting close to quitting all work for OSM because of the idiotic changes done to the standard map. Its getting worse every day and things that actually would be a good thing is voted down by 2-3 people and thats it. So much for community map. Feels like its run by a few people that do what they want.

@anderfo

This comment has been minimized.

Copy link

commented Aug 18, 2015

Apparently, the new style now assumes that every path in OSM is surface=paved, unless surface is set to unpaved or some other value included in an unpaved box.
The problem is that a huge portion, probably >95%, of the mapped paths in my country (Norway) are in fact unpaved and do not have a surface tag. Probably this holds also for many other countries...
So the assumption of all paths being paved is completely wrong, and the needed effort to correct it by tagging surface=[unpaved/grass/mud/dirt/etc] on every path in a country is extreme.

I didn't see this discussion until today.

Please reconsider your decision!

@kiselev-dv

This comment has been minimized.

Copy link

commented Aug 18, 2015

First question is what the differences between highway=path and highway=footway?

As I think, in most cases they acts like classification for pedestrian routes.

  1. highway=pedestrian is on top of that hierarchy
  2. highway=footway right in the middle
  3. highway=path is the lowest level of that hierarchy

We could look for physical differences, but they are not a key. The same way as for primary/secondary/tertiary/residential/unclassified they just indicates majority of a way, they don't give you any guarantees about physical attributes.

For vehicles , we have about 10 classes. From motorway to track even with some subdivision. And for pedestrians there were 3 recognizable levels of pedestrian paths. Actually two of them, be cause pedestrian is dedicated for exact type of city squares and streets.

As good as residential should be stylistically separated from tertiary, and tertiary from secondary, path and footway should be printed differently.

You have hate-letters not because red-dots are better than black dashes. People frustrated because already rather narrow classification of pedestrian way, were curtailed for two classes pedestrian and footway. Actually to one. So now, we have 10 classes to describe ways for drivers, and 1 way class for pedestrians.

Please, Mateusz, you've done a great job, but don't think about path as defective footways - it's a part of pedestrian highways classification. Please, keep those divisioning readable on map.

@Reitstoen

This comment has been minimized.

Copy link

commented Aug 25, 2015

An easy way to see how path and footway is used when it comes to natural trails, is to look at how they are combined with the tags sac_scale and mtb:scale which are mostly used on natural trails.
The pattern is pretty clear:

highway=footway 5.325.275
sac_scale 8.122 (0.15%)
mtb:scale 2.578 (0.05%)

highway=path 3.894.488
sac_scale 234.365 (6.02%)
mtb:scale 138.671 (3.56%)

Having spent hours analyzing the usage and the wikipages for path, footway, hiking, mountainbiking etc. I ended up with the same conclusion.

Please bring back the old way of rendering path different from footway!

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Aug 25, 2015

I guess if we say that footway is kind of artificial (man made) road for pedestrians and the basic path is just some not built (made just by walking) road for pedestrians, we would have covered most of them right.

The remaining problem would be then to treat "paths" that are just a mix of footway with something else (like for example foot+cycle) like something special, other than plain path - probably like highway=generic_mixed_way_for_engine-less ("A generic multi-use path open to non-motorized vehicles").

And it's perfectly doable. I think this change was unfortunate effect of one-way interaction with wiki definitions: proper rendering may need rewriting the definitions, not just wild guessing what is the meaning of what's already written. So for the moment I would step back, work with definitions, and only then come back to rendering.

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Aug 26, 2015

The effort needed to add surface and smoothness tags to all our paths and trails is so extreme that we won't bother.

This doesn't sound like an "extreme" level of effort to me.

it is more important to look at how the "path" tag is described in the wiki and how it is actually being used in quite a large portion of the OSM community

Yes, we did that, and found that while every mapper has their own opinions as to the difference between footway and path, they are all contradictory.

For example, mapper A marks two paths, one as footway and path. Mapper B thinks "oh, that's path, that must mean it's unsurfaced, and the footway must be surfaced". Mapper C thinks "oh, that's path, that must mean it's open to all non-motorised traffic, and that's footway so that means it's only available for pedestrians". Mapper D thinks "oh, that's path, so it must have been created by people walking over open ground repeatedly, and that's footway, so it must have been constructed". Mapper E looks at these same two paths as everyone else and thinks "oh, that's path, so that must be in a rural area, but the footway means it's in an urban area". Mapper F looks and thinks "Oh, that's strange, why did mapper A not just use path for both since it's the modern way to tag all kinds of footpaths". Mapper G realises nobody has actually asked Mapper A why they used different tags, so everyone else has just been making false assumptions.

So what we've realised is that given that after years and years there's no consensus as to what they imply, that it's extremely unlikely that anyone using the map can rely on those hidden implications. So instead of lots of contradictory implied meanings, we're making things easier for everyone, and relying on explicit, clear and certain differences. For now, we're using surface. In the future, we can add more tags, or decide that something else is more important than surface. But if you think there's some inherent difference between footway and path then please realise a) most other people disagree with you - whatever you think the difference is and b) please just be explicit and use a specific tag to show what that differences actually are.

@anderfo

This comment has been minimized.

Copy link

commented Aug 26, 2015

You claim that there is no consensus, but according to the discussion above, in quite a few countries (including mine) there is a consensus, following the guidelines from the OSM wiki. The confusion example of yours wouldn't happen in our parts of the world.
I don't see any reason to realise that "most other people" disagree with me, at least not from reading this thread, looking at OSM statistics or looking at examples from places I have visited.

The "extreme effort" i described above isn't extreme for one single path, but when you multiply it with the number of paths, then multiply it with the number of segments the paths will need to be split into (in order to tag correctly with surface, smoothness, width, etc.), and the number of hiking and mountaineering trips we would need to actually get those tags correctly placed, it becomes a lifetime effort for thousands of people.
And all this effort would be needed just in order to correct the ugly rendering problems that was introduced a month ago... which now tells us that the Norwegian mountains probably have several thousand kilometers of paved trails (!) of the same type as we have in the city centre. They are now identically rendered. For example these two trails are now identical:
A) http://folk.ntnu.no/anderfo/pics/2014-08-16-Ramsh%C3%B8piken/2014-08-16%2010-48-18%20DSC04151.jpg
B) http://images.eie.no/boliger/13002281/218138892_2748.JPG

@Gazer75

This comment has been minimized.

Copy link

commented Aug 26, 2015

@pnorman So you don't think its extreme to split the trails into several hundred sections of maybe a few meters long to add proper surfacing? Thats never going to happen, trust me...

The map is just more confusing for me with the combined render. It is impossible to know if the path is a built footway, usually gravel surface outside built up areas, or a naturally made path that is usually only about 0.5-1m wide.
Changing the render because of inconsistency in tagging across the world is the wrong way to go IMO.

At least OsmAnd is still rendering them separately...

@systemed

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2015

👍 to @gravitystorm.

Most of the assumptions here are specific to one or several countries. For example, saying that since highway=path is often used with sac_scale=* it must indicate a rural trail, is not helpful in countries where sac_scale is rarely used, such as the US or UK. (Funnily enough, the Schweizer Alpen Club is not a well-known organisation in English-speaking countries. ;) ) Please realise that, just because something works in your backyard, doesn't mean it works across the whole planet.

To the best of my knowledge, I do more post-processing of path and surface tags for cycle.travel's rendering and routing than any other online data consumer. From bitter experience I can assure you that it simply isn't reliable to assume surface based on footway vs path. What you can do with a modest degree of certainty is look at the surrounding area. In a rural area, where a surface tag or similar is not supplied, both path and footway are more likely to be unpaved than paved. In an urban area, they are more likely to be paved. But integrating that into the osm-carto toolchain is unrealistic and introduces too much 'magick' for mappers.

The correct solution is simply to add a surface or tracktype tag. Because OSM is iterative, you can use a general tag (surface=unpaved) at first, and mappers will later come along and improve it (surface=gravel, surface=dirt). So @anderfo, when you say

it would be quite simple since we could just search and replace path by the new tag (whatever that would be) and never use the path tag for anything

that's very easy: just search and replace 'highway=path' with 'highway=path, surface=unpaved'. Job done.

@zdila

This comment has been minimized.

Copy link

commented Aug 26, 2015

Please realise that, just because something works in your backyard, doesn't mean it works across the whole planet.

OK, got it: US and UK are the core of the world and everything else is just a backyard ;-)

that's very easy: just search and replace 'highway=path' with 'highway=path, surface=unpaved'. Job done

Mass / automated edits are forbidden in OSM.

@anderfo

This comment has been minimized.

Copy link

commented Aug 26, 2015

@gravitystorm and @systemed - How big parts of the world do you believe have this path/footway confusion? I've only heard of those problems in UK...not in any other country. So I wonder if it's a very local problem in your area, instead of the other way around.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

Mass / automated edits are forbidden in OSM.

That's not true (there are specific rules, though).

@systemed

This comment has been minimized.

Copy link
Contributor

commented Aug 26, 2015

OK, got it: US and UK are the core of the world and everything else is just a backyard ;-)

No, I didn't say that. Please don't put words in my mouth, it's not conducive to a good discussion.

Mass / automated edits are forbidden in OSM.

No, they are not. There is a well-documented process for carrying out such edits. If you can convince the community that your edit is good, it will be approved.

How big parts of the world do you believe have this path/footway confusion? I've only heard of those problems in UK...not in any other countries. So I wonder if it's a very local problem in your area, instead of the other way around.

If only that were the case, but no, highway=path is a difficult tag the world over. For just one example, one of my biggest rendering problems in France is that broad, adapted cycle trails are often tagged as highway=path; whereas in this case, the German-speaking countries and the UK are actually closer in practice, and they would be tagged as highway=cycleway or highway=track with a surface tag. So again, highway=path on its own does not give you a reliable indication of the nature or quality of the path.

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

@gravitystorm

So what we've realised is that given that after years and years there's no consensus as to what they imply, that it's extremely unlikely that anyone using the map can rely on those hidden implications.

While this intuition was perfectly legit (I also supported it initially!) and I understand the urge to have something we can rely on instead of many different assumptions, here are some thoughts I have about it now:

  1. When in doubt, it's always good to ask first. Wiki is the main source of documentation we have, but it's not set in stone - OSM is all about communication and agile cooperation. We already understand rendering is part of the loopback for mappers, but it's reasonable to notice that it may be equally important for crafting, tuning and fixing definitions.
  2. 10 years may look like forever, but now it's stirred enough (thanks to the sudden change) to have a second thought, because this time it's something real and people are more than ready to solve the problem.
  3. OSM is also about consensus. Given that so many people are against the change, it is also good to step back. I personally don't mind for it that much, but why support the tension?

For now, we're using surface. In the future, we can add more tags, or decide that something else is more important than surface.

I'm happy you think about the future, because current situation is not "stable" and I hope it will be resolved - this way or another.

@imagico

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

Yes, we did that, and found that while every mapper has their own opinions as to the difference between footway and path, they are all contradictory.

While that is true you should not forget that this is also the case for a lot of other features that are distinctly rendered in the map. The question is IMO not how many opinions there are on the exact meaning, it is how well defined actual use of the tag is. In case of path/footway this varies a lot internationally as well but regionally and in specific countries it is often fairly distinct what kind of features highway=path and highway=footway are used for when applied without supplementary tags. In light of this it is perfectly understandable if people think this difference should show up in rendering and it should not be considered irrational or without basis to desire such a distinction.

One problem with supplementary tagging is that there is currently no established tagging for making the distinction between a built footpath and one purely established by use independent of the setting. The surface tag describes the material but not if this material is placed there by construction work or if it just happens to be there naturally. surface=ground could be considered to imply 'natural state' but in reality does not. surface=grass can also frequently mean both. And sac_scale specifies technical difficulty, an established path on a salt pan does not have this. You could of course go to tag all established, non-built footpaths with sac_scale=hiking but i am not sure if this is such a good idea.

So the question maybe is more: how do the proponents of a unified rendering of footway and path suggest the difference between a constructed footpath and one merely established by use should be tagged?

(i realized this is kind of off-topic here - feel free not to reply, but in general this is still a highly valid question IMO)

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Aug 26, 2015

then multiply it with the number of segments the paths will need to be split into

Why on earth would you have to do that? A minute ago you were happily tagging many kilometers as one way tagged highway=path with an implied (to you) surface=unsurfaced. So nobody is asking you to split the way every few metres (as you've also said on the norwegian talk list).

it becomes a lifetime effort for thousands of people.

Oh come on - this is becoming an unproductive discussion.

@Gazer75

This comment has been minimized.

Copy link

commented Aug 26, 2015

👍 @imagico Thank you. This is what I have been thinking as well. There is barely any difference on paths with different surfaces now that I can see. And tbh that detail is probably best left for a more specialized map. But having a separation of a naturally made path and a built one was really nice.
If only the tagging was consistent...

Knowing if a path or footway is natural or not will tell you quickly what footwear to use. Using footwear that you would normally use on a foot- or cycleway in the city would not be wise on a natural trail ;)

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Aug 26, 2015

So the question maybe is more: how do the proponents of a unified rendering of footway and path suggest the difference between a constructed footpath and one merely established by use should be tagged?

I'm not going to suggest tags, and I'm not going to suggest that "constructed" is even an important attribute. After all, does it matter if a 1m wide smooth dirt path in a park was constructed 15 years ago by digging out the grass, vs a 1m wide smooth dirt path in a park that formed due to the passage of many feet? Would this difference ever be something to show on this map? I doubt it.

The discussion can be widened out to be more or less like this:

  • "Given all the footpaths[*] in the world, does it make sense to render them with more than one style?"

In my opinion, yes it does. There's a wide variety of different types of footpaths. I note here, however, that many maps, even those using OSM data, including hiking-related maps, just show all footpaths in one particular style - it's not common cartography to have many different types of footpath renderings.

  • "Given the desire to show different footpaths in different styles, which real-world attributes of the footpath are the most important?"

There's obviously a big choice here, from surface, width, smoothness, construction, technical difficulty, use in long-distance routes, visibility, legal status, accessibility, overgrowth, drainage and so on. Some of these are tagged in OSM, some very rarely. But since it's impossible to show all the different possibilities (there are several thousand combinations of just the above values), a cartographer needs to decide how many "buckets" to have, and then how to put each footpath into only one "bucket".

  • "Given all the possible ways to put footpaths into buckets, which one shall we use here?"

This brings us back to square one, where we realised that highway=path vs highway=footway was not in itself the best way to distinguish all the different types of real-world footpaths, as per (endless) discussions above regarding implied meanings.

Of course, if anyone disagrees on creating buckets based on surface, fair enough. If you think that the buckets should be based on some other attribute(s) of footpaths, then make a proposal.

[*] for the purposes of this comment "footpath" means all types of footway, paths, trails, etc in the general route-for-walking-on kind of way

@zdila

This comment has been minimized.

Copy link

commented Aug 26, 2015

I agree to distinguish footpath rendering according to surface, but let assume that highway=path is unpaved and highway=footway is paved. The description on the wiki doesn't say that directly, but from the description of the path I have the feeling that it is per default more like unpaved than paved and from the description of the footway that it is per default more like paved than unpaved. Also the illustration images say so.

If we agreed upon this then the descrition on the wiki could be improved afterwards.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 26, 2015

If we agreed upon this then the descrition on the wiki could be improved afterwards.

Place for discussion like this is on OSM wiki and/or tagging mailing list.

Note that in cases where I think that it is beneficial I start such discussions - here I think that redefining tags with usage counted in millions is a poor idea so I will not propose redefinition of highway=path.

For purposes of rendering - I think that treating highway=path and highway=footway differently is a poor idea, going against documented meaning.

I am also currently working on change that is supposed to fix #1765 and #1766

@kocio-pl

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

Place for discussion like this is on OSM wiki and/or tagging mailing list.

+1

Note that in cases where I think that it is beneficial I start such discussions - here I think that redefining tags with usage counted in millions is a poor idea so I will not propose redefinition of highway=path.

I don't see the number of usage as an argument against fixing definitions. It's maybe even more important to clean them as much as it's possible.

@zdila

This comment has been minimized.

Copy link

commented Aug 26, 2015

I think that redefining tags with usage counted in millions is a poor idea so I will not propose redefinition of highway=path

If rendering will assume some defaults for path or footway, then I think it should be mentioned in the wiki.

If definition of the path is unclear and everybody explains it differently then should we never fix/update the definition just because there are millions of usages in the OSM?

@anderfo

This comment has been minimized.

Copy link

commented Aug 26, 2015

According to the comments in here, we need some sort of alias for "highway=path, surface=unpaved" so that we can more easily map/tag ordinary paths.
It is a hassle to need to add surface=unpaved to every path we map (and to every path we have already mapped).

It feels just as redundant as adding foot=designated to a footway, bicycle=designated to a cycleway or trail_visibility=excellent to a motorway. But apparently some people think it is necessary.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 26, 2015

According to the comments in here, we need some sort of alias for "highway=path, surface=unpaved" so that we can more easily map/tag ordinary paths.

And it means nearly nothing - as this place is not a proper place for discussion about tagging. It is place to discuss how already tagged data should be used according to current tagging schemes.

If definition of the path is unclear

I would happily reply to this question on tagging mailing list or OSM wiki - but not here.

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Aug 26, 2015

And it feels just as redundant as adding foot=designated to a footway, bicycle=designated to a cycleway or trail_visibility=excellent to a motorway.

Not really - the statistics that @imagico gathered showed that, where tagged, highway=path has a paved surface around 25% of the time. Of course, many of the paths without an explicit surface will be unsurfaced, and probably more than 75% of those. But a significant fraction of highway=path are actually surfaced.

Unlike trail_visibility!=excellent on a motorway, which is absurd and again not helpful to the discussion.

@zdila

This comment has been minimized.

Copy link

commented Aug 26, 2015

Of course, many of the paths without an explicit surface will be unsurfaced, and probably more than 75% of those. But a significant fraction of highway=path are actually surfaced.

If there are more paths without an explicit surface unpaved then why are all such paths rendered as paved?

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

If there are more paths without an explicit surface unpaved then why are all such paths rendered as paved?

Issue #1766 is about default surface assumptions, not this one.

@zdila

This comment has been minimized.

Copy link

commented Aug 26, 2015

Issue #1766 is about default surface assumptions, not this one.

I apologize. I've copied that question to #1766.

Repository owner locked and limited conversation to collaborators Aug 26, 2015

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Aug 26, 2015

At this point we're just circling around and not getting anywhere productive. A couple of closing thoughts:

OpenStreetMap Carto is not removing the difference between highway=footway and highway=path in OSM. It remains, as ill-defined as before. We are a data consumer, deciding how to best make a map. There are plenty of other cases where two different tags in OSM are not rendered differently in osm-carto. We've also done this with bicycle=designated and horse=designated highway=path for a long time, and highway=residential and highway=unclassified and the various water area fills are other examples. Most other styles do this too, as a features they want to render may correspond to multiple sets of tags.

We are not impacting people making their own maps. In fact, if the current rendering leads to increased use of surface, this will significantly help them.

If we were to re-introduce different renderings for highway=footway and highway=path, in addition to the criteria from @gravitystorm above, we'd need to find something that makes it clear by looking at them what the difference is. With motorized highways (primary>secondary>tertiary>residential/unclassified) this is done with hue and intensity, to show a progression. Simply rendering them in a visually distinct way isn't enough - this is a map, not just a 2D visualization of the database.

Edit: Missing word

@matkoniecz

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 26, 2015

@pnorman - errata:

There are plenty of other cases where two different tags in OSM are rendered differently in osm-carto.

"are rendered differently" should be "are not rendered differently".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.