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 _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
