[Talk-us] Usage of highway=track in the United States

Kevin Kenny kevin.b.kenny at gmail.com
Wed Feb 24 16:39:47 UTC 2021


On Tue, Feb 23, 2021 at 2:57 PM Richard Fairhurst <richard at systemed.net>
wrote:

> Kevin Kenny wrote:
> > Routers tend to get it right, since most of their algorithms
> > disfavor service roads and penalize tracks severely. Essentially,
> > you'll get routed over either only if they go to your destination.
>
> That's a rather car-centric attitude!
>
> Having useful data for highway=track would be really helpful in bike
> routing, particularly for those of us who ride steel rather than carbon
> fibre! There's a burgeoning industry of "gravel/adventure" bikes for
> people who enjoy off-road riding but without all the technical malarkey
> associated with MTBs.
>
> As it stands, for cycle.travel's routing, I ignore highway=track in the
> US by default unless there's another useful signifier - a surface tag, a
> route relation, or similar. Contrast that to mainland Europe, where
> cycle.travel will happily route over highway=track because the data is
> much more reliable.
>

Not car-centric at all! 'A router' says nothing about whether it's routing
for car, bicycle, pedestrian, or horse. The rules for what ways are
suitable differ, but routing is routing. "Find me a way to get from here to
there that is optimal according to some metric and satisfies some set of
constraints."

I'm actually making the argument, somewhat obliquely, that I'm having
trouble discerning very many purposes for which the current definition of
`highway=track` is fit. `highway=track`, I have been told repeatedly and
firmly on this list, refers only to the purpose of the road.  Whether a way
comprises two ruts or tar-macadam ten metres wide, it's a track if its
purpose is agriculture or logging. If I discover that someone has a shale
pit, it has to become `highway=service`. Likewise, if I find out that
there's a cabin in there somewhere, it's now `highway=service
service=driveway`.  If there are *two* cabins there, belonging to different
establishments, now it's `highway=residential`. In no case is anything
asserted about rideability, driveability, access, or surface
characteristics.

It tends to be Europeans who are sticklers for the rule that
`highway=track` refers only to purpose. I don't hear that nearly as often
from this side of the pond, so I don't think the tagging issue is
specifically an American problem. One difference in the US is that we have
a lot more relatively empty space, and so we have a lot more poor-condition
tracks that are not fit for riding, don't get snow removal, and have the
brush cleared only when the forester needs to get in with more than an ATV.
That's not a problem with the map, it's a problem with the territory. The
things are built for, and get used by, off-road vehicles, be they jeeps,
tractors, snowmobiles, or logging trucks. There isn't a classification
below 'track'. Our tracks are simply often not well maintained.

I therefore argue that calling something `highway=track` based on field
observation until and unless the purpose of the road is known is mostly
harmless. The definition of 'track' that is based solely on purpose is not
terribly useful for routing decisions, be it a gravel grinder, a car, an
ATV, a hiker, a snowmobile, or a mule.  It's also a definition that makes
things difficult for a rural mapper to map in a forested area, since the
portion of the way that's been surveyed may not be informative about its
ultimate purpose - without traveling the entire length of the way, it may
not be possible to identify what to put in `highway=*`. And it makes only
fairly trivial differences to rendering. For most intents and purposes, a
track, a service way, or a rural residential way are equivalent.

Perhaps the issue among that list that troubles me the most is the
difficulty of choosing `highway=*` for the two tire tracks that disappear
out of sight into the woods. I've mentioned that before, on this mailing
list and on "tagging", and the consensus of the replies appears to have
been that if I don't know the ultimate purpose for that poor road, I
shouldn't map it at all!  That strikes me as a ridiculous extreme. I know
the surface, smoothness, tracktype, and so on of the portion that I've
explored. I know that it's useful to hikers, cyclists, equestrians,
snowmobilists, whatever, along the portion I've traveled. I know its
alignment. But I can't map it because I don't know why it was put there?
Really?  `highway=track` at least asserts that the road is there, and I
argue that it's a perfectly fine placeholder until and unless there's
better information. (And I don't personally consider collecting that
information to be a particularly urgent task - the distinction is not
likely to affect anyone's life in the slightest.)

This is a more general pet peeve of mine. If a tagging scheme requires me
to do research beyond the characteristics that I can observe in the field
on a mapping trip, that's a bad tagging scheme.

I have yet to see a convincing reply to the question: "What would a data
consumer want to know, that would be informed by the distinction among
'track', 'residential', 'service' and possibly even 'unclassified' as
applied to relatively unimproved rural roads?"  The answers tend to be
dismissive ones like "we care about reality."  (With the implication that I
don't care about it?) What is so important about the road's purpose that
makes people go so far as to say it shouldn't be mapped until and unless
that information is known?

I do try to make it a practice to tag surface, tracktype, smoothness and
sac_scale when I'm mapping a track, path, or footway. I don't tag mtb_scale
because I don't have the specialized knowledge to grade a MTB track
correctly. (Being a hiker, I'm a lot more confident about sac_scale.) I
also am pretty careful to map surface, smoothness, tracktype on roads of
higher classification (typically unclassified or tertiary) if it's poorer
than the highway class would lead one to expect. There are some
`surface=compacted smoothness=bad` tertiary roads out in the countryside
around here. But around here, data out in the woods are pretty certain
always to be stale. It simply comes from having such a low population
density. There's only so much ground that a mapper can cover. When I happen
to go somewhere, I update the map of where I've been. I can't assert more
about the data quality except that it'll be pretty good until the next
washout or blowdown, and I don't know when I'll be back to the spot to
observe it again.

(Feel free to stop reading here, because I'm repeating a point I've made
many times...) For the scale of the problem:  The Northeast is the most
densely populated part of the US.  Even in the densely-populated
Northeastern states, we have some huge areas of unsettled land. The
Adirondack Park has a land area comparable to that of Belgium, and a
population of about 100,000. There is no cellular service or broadband
connectivity in most of that region Even satellite service can be
problematic unless trees that obstruct the antenna can be cleared. Other
infrastructure is equally primitive. There are no geeks, because there are
no geek jobs. You're not going to build a huge online mapping community in
an area like that. What little mapping gets done is done by crazy geek
adventure-tourists like me who enjoy getting up that way. We're few.  And
this is the Northeast. The 'fly-over country' has those problems in
spades.

-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20210224/71a0b4ab/attachment.htm>


More information about the Talk-us mailing list