[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

Richard Fairhurst richard at systemed.net
Sun Aug 18 16:25:01 UTC 2019


Sarah Hoffman wrote:
> On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> > Peter Elderson wrote:
> > > The point is, as it is it's not good enough for data use besides 
> > > rendering. you can't rely on route relations for anything but
> rendering
> > 
> > Once again: pretty much every OSM-based bike router uses route relations
> to
> > influence routing. (That might give you a clue to one of the
> strategies.)
> 
> But this is a task which is essentially the same rendering. 

I was addressing Peter's point that route relations can only be used for
rendering, which is demonstrably false - they're used for influencing
weighting in routing.

> The problems come in if you want to go the other way. When you start with 
> the relation, want to determine where the route goes along. That
> information 
> is simply not contained in the route relations as long as you don't impose
> a
> couple of restrictions. [...]
> I consider sorting and the use of roles essential for that.

I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse'
roles for bike route relations dates back to the earliest days of bike route
mapping in OSM and is well established by now.

But just as long established in OSM is the principle that - since mappers
are our most precious resource - we optimise for the mapper, not for ease of
consumption. Allowing relations to be unsorted is an example of that. If a
relation represents a linear route, it's a SMOP to put the ways in the right
order. 

There are two obvious strategies. 1 is: create an empty polyline P with
endpoints P1 and P2; iterate through the relation members; every time you
encounter a way with an endpoint P1 or P2, add it to the polyline
(potentially in reverse order) and remove it from consideration; repeat
until there are no ways left. This is broadly the approach I've used until
now.

2 is more involved but more fault-tolerant and flexible; create a routing
graph, then route from the relation's startpoint to its endpoint using a
very heavy uplift for members of this relation. This is a useful approach
where the route actually _is_ non-contiguous but you nonetheless want to
include connecting routes between the sections. (Quite a lot of American
rail-trails are like this, as are several UK National Cycle Network routes.)
This is an approach I'm investigating at present.

Approach 1 does of course fail if the relation doesn't represent a single
linear route. That would, however, still be true if the route was ordered.
There's probably a little more that editing software can do here, but unless
you want to require people to have 12 months of OSM experience before they
can map a change to their local cycle route, ultimately the solution is to
have better QA tools. Something like OSM Relation Analyser is faultless
algorithmically but the UI is less than immediate. If we were to have an OSM
Inspector-like view of lacunae, spurs and other relation issues, it would be
a whole lot easier to fix them. I occasionally wonder about coding this but
I'd love it if someone were to beat me to it.

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html



More information about the Tagging mailing list