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