<div dir="ltr"><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 19 Aug 2019 at 15:40, Peter Elderson <<a href="mailto:pelderson@gmail.com">pelderson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ideally, you should not have to create gpx-s from them and you should need no ordering or routing at all, because they ARE the routes. An app or gps-device should use them as is, just tell the user what to do next. Since no app currently does that (future still has to arrive) we resort to transferring the route to them as tracks, i.e. gpx.</div></blockquote><div><br></div><div>Now we are getting closer to the point. You are correctly saying "no app is currently doing that". So why should we sort topologically non-sortable route-relations members? We have a solution that works with existing tools on unsorted hiking/cycling routes, and that is routing with strong preference on the use of ways that are part of cycling/hiking routes.</div><div>I see the problem from the mapper's perspective (as I map a lot) and from the end-users perspective (I very often design bicycle tour routes from OSM data). <br></div><div>I am not a data consumer in the sense I do not write software thta uses OSM data, I am an end usere, eclusivley using the software produced by others) and I acknowledge that  my experience is limited to cycling/hiking routes. I am sure there are routes that have different problems and may need sorting, One such category are most likely public transport routes, which are used in a completely different way.</div><div><br></div><div>Volker<br></div><br></div></div>