[Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[brad]

On 5/26/20 8:26 AM, Kevin Kenny wrote:
> On Tue, May 26, 2020 at 6:59 AM Andrew Harvey <andrew.harvey4 at gmail.com> wrote:
>>  From what I can tell, the ask is a tag for a specific type of way which the person needs experience or preparedness before undertaking. But I'm lost and still not completely understanding what exactly this new tag would cover exactly and what it wouldn't.
> I've said repeatedly - but people are not listening - that what's
> needed is the opposite. More specific ways to tag the hazards of a
> technical trail is the exact opposite of what I want.
>
> A data consumer cannot draw any inference from the absence of a tag.
>
> We already have an enormous cauldron of tag soup to describe
> smoothness, surface, width,incline, steps, visibility, tracktype,
> overall technicality (sac_scale, mtb_scale), and $LC_DEITY knows what
> else, to characterize specific hazards. Many of these (smoothness,
> surface, visibility) have ways to characterize freedom from those
> hazards. Some (most notably sac_scale and mtb_scale) do not. This lack
> is _part_ of the problem, so _part_ of what I want is to be able to
> say something like `mtb_scale=0` or `sac_scale=no` - to say, "this way
> is non-technical." But that's a very minor issue.
>
> i don't think that it's going to work to have to enumerate every
> possible hazard and assert that a way is free from it. Rather, in
> general, for a footway, we need a way to assert 'this path is
> generally OK for a person with less-than-ideal physical fitness or
> small children in tow." For a cycleway, we need a way to assert, "this
> path is generally OK for a road bike." This assertion cannot be made
> by omitting tags. A router cannot tell the difference between 'the
> mapper didn't say anything about difficulties or hazards', and 'the
> mapper thinks it's OK.'
>
> (Feel free to stop reading here. The rest of this message tries to add
> detail. The key point is "a positive assertion that the given way is
> OK for a pedestrian/cyclist of ordinary ability".)
>
> ----
>
> The assertion needs to be as simple as possible.  which is what leads
> to the discussion of separating urban paths from technical trails
> using a top-level key (and the misconception that there's actually a
> difference between `cycleway` and `path`).  I agree with the others
> who say that train left the station a long time ago, and we're
> unlikely to catch up with it to board it.
>
> What I'm asking for is some minimal set of tags, that we can expect a
> mapper to provide as a matter of course, to assert that a way is free
> from unusual hazards. To assert that a walker of ordinary ability,
> dressed in ordinary street clothes, and perhaps with small children in
> tow, can use the path. To assert that a cyclist of ordinary ability,
> aboard an ordinary road bike can ride it. Adding more tags to describe
> that something does have difficulties or hazards will not help.
>
> Emphasis there is also on the word, 'minimal'. What is the minimal
> information that a mapper needs to provide to let a router draw that
> conclusion? Obviously, if we were civil engineers assessing trail
> safety for people with disabilities, small children, or racing wheels,
> we'd have a lot of formal evaluations to conduct. But if I have to
> bring a clinometer (or transit and rod, etc.), make the delicate
> distinction between pea gravel and compacted-mixed-gravel-with-fines,
> or cobblestone and sett, and so on, before I can say, "this is a
> regular old path in the city park", it's not going to happen!  The
> best I can do is to presume that whoever built the path did the job,
> or do the required analysis on a set of ways that's too small to be
> really useful.
>
> The other side of the same coin is that I shouldn't need expert
> knowledge and a detailed characterization of the hazards to be able to
> map, "nope! Not going there today!" We enjoy over-classifying
> everything, and making the fine distinctions is wonderful. But how far
> would we have got in mapping if a mapper couldn't say, "there's a
> bridge here" without needing to know the difference between a
> king-post and a bowstring truss?
>
> All of the tags that assert technical hazards are, in the current
> scheme, trolltags. We've rejected that sort of thing for cars. We no
> longer say `highway=tertiary demolished=yes` or `highway=tertiary
> construction=yes` because we recognize that the secondary tag says,
> "just kidding! You actually can't drive on this!"  We realized that
> routers for cars can't make effective use of an entirely open-ended
> set of tags that all say, "don't use this road", and we've changed the
> schema to fix it, with things like the lifecycle prefix.  I want the
> same level of respect for walkers and cyclists.
>
> It comes down to two basic questions:
> - What is the minimum set of information that a mapper needs to
> assert, to have a bicycle or pedestrian router assess that a way is
> usable by a pedestrian or cyclist of ordinary ability?
> - What is the minimum set of information that a data consumer needs to
> take into account when making that assessment?
>
> By paying careful attention to eliminating trolltags, we've nearly
> answered this question for cars, so our auto-routers like OSRM have
> become at least passable. We're not nearly as far along with the
> bicycle infrastructure, and in fact, I first encountered this issue
> because I was probing with a router to make sure that a major
> rail-trail in my neighbourhood was routable for bicycles, and found
> that it would have sent me between two parks on a difficult MTB trail.
> (I fixed the immediate problem by tagging the trail in question with
> `surface=ground smoothness=very_horrible`, but I'm not expert enough
> to assign an `mtb_scale`.)
>
> I strongly suspect that most of what is mapped in the pedestrian and
> bicycle infrastructure lacks some required information. So be it. We
> can't fix it until we've at least characterized the problem.
>
> I anticipate that the next argument will be that the distinction
> between 'OK' and 'not-OK' is subjective. The only way to have it be
> objective is to subject every way in the database to a detailed
> engineering analysis that few of us are qualified to make. (I _am_ an
> engineer by training. I can state with absolute certainty that
> assessing a footpath for compliance with applicable standards of
> construction and accessibility is outside my professional competence,
> and I am not licensed to certify plans in that domain.) But most of us
> can make a rough distinction, and even a rough distinction, leaving
> the corner cases and hidden hazards to the engineers, is better than
> nothing!
Yes!  We have an overload of tags for trails, many poorly defined, many 
rarely used.   KISS -  keep it simple stupid.  I think it would help if 
we narrowed the focus for cycleway and footway.
How about this, as default:
cycleway - paved path that a typical tourist or casual rider can ride on 
a road bike.
footway - smooth path, very firm surface or paved that is good for 
someone with less than average ability.
bridleway- for exclusive (or almost exclusive ) horse trails
path - for everything else.   Implies not paved.  Routers should not 
route road bikers here.

The difficulty for bikes (& maybe hiking) can be simple green/blue/black 
similar to what is used on US bike trails, and ski areas.