[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)
pelderson at gmail.com
Sun Aug 18 19:28:03 UTC 2019
Richard Fairhurst <richard at systemed.net>:
> 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
> > 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.
Ok, I agree you can use membership of a route relation as a weight factor,
while you do routing. You don't use the relation as a route. The idea of
walking routes is that they are the route and you follow the route, partly
or with own adaptions, but not for rerouting.
I did not mean that they can only be used for rendering. The point I made
is that if there are interruptions, branches, duplicates, stray nodes,
nested relations, etc in a route relation, it can still be used for
rendering (or, for granting weight to individal ways when routing), but you
cannot use it as a route that you follow from A to B by the ways it
> > The problems come in if you want to go the other way. When you start
> > 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
> > 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.
How then do I get it in OsmAnd and have it guide me forward the entire
route, then backward the entire route? Or in a Garmin device? Mine does not
have the option, as far as I know. I can do a lot, but it requires getting
the OSM data organized exactly as required, and involves gpx transfer and
route editing software, and in the end, Garmin reroutes the whole thing
again, to arrive at exectly the chain of ways I started with in OSM. The
main point is, as you say, data quality. QA tools can find problems, but
the fixing is still up to the mapper. RA does things, but can simply not
handle complex walking route relations.
JOSM does a decent job in detecting problems and it provides decent fixing
tools. E.g. sorting. But that often fails when the route is broken. Just
like overpass turbo export has a sorting routine, which works for simple
ordering tasks but just gives up if it gets complicated. Sam with
waymarkedtrails: its fine when simple ordering problems are there, it also
handles hierarchies quite nicely, but if it doesn't work out completely it
gives up and gives the relation as is.
I would sure like a better QA tool. I also would like a sorting routine in
JOSM that can handle all the complexities that prevent the full sort. If
anyone has goed code for that and knows how to make that available as a
plugin, that would be a great asset in maintaining OSM walking routes. I'm
often sorry I am no good at programming.
> 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
> 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
> Sure. The problem is that walking relations often do not add up to a
linear route when sorted. If they do, that doesn't last very long. So you
can't presume that they are, so it's up to the mapper to do it.
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
> 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
> 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.
The problem is, the route relation is often meant to be a single linear
route, but in fact it isn't.
> There's probably a little more that editing software can do here, but
> 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
> Inspector-like view of lacunae, spurs and other relation issues, it would
> 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
I'm afraid testing is all I can offer. I could list problems to detect, but
I think I would not be telling you news. Very important: handle nested
relations (hierarchies). RA currently does not.
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> Tagging mailing list
> Tagging at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging