I completely agree with your assessment, Greg.

I discovered this tagging scenario after it was a done deed and was trying
to be diplomatic about suggesting the changes. Like you, when I want my
Garmin to use a certain route I add intermediate via points to that end.
Will's trick has the benefit of the user not needing to know in advance
about the road condition but, as you say, and as I recognized in my comment
to him, it isn't really legitimate.

In this particular case, it would seem that highway=track is not so far off
the mark. And if the bridge is truly gone, routing preferences become a
non-issue immediately. I'm planning to do a trip in that area next summer
and I'll try to provide a short summary of what I find when I do.

On Sun, Sep 24, 2017 at 11:02 PM, Greg Troxel <g...@lexort.com> wrote:

>
> Dave Swarthout <daveswarth...@gmail.com> writes:
>
> > I came across an interesting routing problem the other day. A section of
> > the Richardson Highway in Alaska was relocated in 2015 by the Alaska DOT
> in
> > anticipation of erosion or flooding by the nearby Delta River. However,
> the
> > old highway is still present, is still paved, and is shorter than the new
> > highway that replaced it. OSM mapper Will Lenz classified the old highway
> > as a track to "persuade" his GPS's routing algorithm into using the new
> > section. See the following changeset and the conversation I had with Will
> > here: http://www.openstreetmap.org/changeset/47049836.
>
> Changing tags to make a router do something, when the tags are not
> accurate is "tagging for the router" and not ok, in the same sense that
> "tagging for the renderer" is not ok.
>
> Certainly as sections become unpaved, bridges no longer work, those
> features should be reflected in the map, and that will pretty quickly
> (instantly in the case of bridges) cause routing to flip to the new way.
> So perhaps this is already no longer an issue.
>
> > Clearly, the old highway is not a track using the Wiki's definition. I
> > might be tempted to tag it as highway=unclassified, or perhaps service,
> but
> > none of these solutions is ideal. Will's idea works but is not, strictly
> > speaking, proper.
>
> unclassified, or maybe even tertiary (assuming AK 4 is secondary, being a
> state highway) seems ok.  The real point is lanes, surface, maxspeed and
> maxspeed:practical, in terms of how routers behave.
>
> A big question is how the authorities view use of the road.  If it's
> perfectly ok to use it, then it seems that it's just a matter of
> preference for someone to want to use the new section instead.   If it's
> posted not to use it, then access tags are in order.
>
> A router ought to be constructing an estimate of how long it takes for a
> given path, and the distance.  Then allocating penalties for things that
> are not about time/distance, like bumps endured, and then choosing a
> path with some minimum of a compound metric.  Generally highway
> classification will have little to do with this, but surface, lanes,
> speeds, traffic lights, etc. will of course matter.
>
> The obvious experiement is to drive both ways and record the experience,
> and then figure out how the map data transforms into time/distance
> estimates, and see where those estimates are incorrect, and if there are
> serious instances of that, fix the map.
>
> But if the old road is faster and shorter, a router saying to take it
> is not wrong.
>
> Someone who prefers a route that is longer is not wrong to have that
> preference.  But they need to be able to communicate that preference to
> the router, rather than expecting their preference to be encoded in a
> subtle, hard-to-follow manner in the map.  An obvious method is to
> select an intermediate waypoint along the new road.  I do this when I
> want to force a particular route (because I know about
> traffic/construction, or just because I find a less crowded road more
> pleasant, even if it does take longer).
> .
>
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to