You can't seem to let go of your routing. The routes in OSM represent routes that are already there. They are sequences of ways to follow in the order given, not sequences of points to route to.
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. Exporting as a gpx loses the way information. THEN you need rerouting, to turn them back into a chain of censecutive ways to follow. The rerouting should return exactly the original route. Of course this only works when the routing software uses exactly the same map, i.e. knows exactly all the ways used to create the transport gpx-file. Some imperfections in various stages can be helped by routing. his means you get a route over a gap, but you can't be sure it will be the waymarked OSM-route as it is found on the road. Routing along with planning is a big help in trip planning, but it should not touch the route itself. So, it's not all about getting there. It's about doing the way. As hikers use to say, the way is the goal. Very Tao. Fr gr Peter Elderson Op ma 19 aug. 2019 om 14:46 schreef Volker Schmidt <vosc...@gmail.com>: > Maybe it's the summer heat, or my age, but I still don't get the essential > step in both Sarah's and Peter's reasoning. > Let's assume that for hiking and cycling type relations I do have all > component ways in some, generally agreed, -sequence in the database. > How do I get this information out of the database and converted nto a > navigation aid for me as end user? > I see four basically different options: > 1) a paper map or a sequence of paper maps > 2) a road book with turn instructions > 3) a GPX track to follow on a navigation device > 4) real time navigation with turn instructions on a navigation device > > All four do not need the sorting of the relation members under the > condition that the routing algorithm gives very strong preference those > ways that are part of a hiking/biking route relation. > > There is theoretically a fifth option: > I tell my intelligent navigation device "bring me to route XVZ and guide > me along that route in direction N / S / E / W > But also in that case the sequence of the ways in the route relation seems > irrelevant. > > I must be missing a crucial point in your reasoning. > > Best regards > > Volker > > On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann <lon...@denofr.de> wrote: > >> On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote: >> > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann <lon...@denofr.de> wrote: >> > >> > Assuming we don't care what happens to really botched relations, all >> cases >> > > except one that I listed initially are covered with one single simple >> > > instruction to the mapper: sort your route. >> > >> > I strongly disagree with this advice, at least as far as cycle routes >> are >> > concerned (disclaimer: I have mapped many bicycle route relations) >> > Even many run-of-the mill "linear" (A-to-B) routes have the problem that >> > the the precise A-to-B route is different form the B-to-A version of the >> > "same" route. The reasons are mainly >> > >> > - roundabouts >> > - one-way cycle paths >> > - oneway streets without bicycle:oneway=no (frequent in >> agglomerations, >> > the route A-to-B uses different streets from the B-to-A route) >> >> > At the practical level it is impossible to sort these route relations >> > automatically (in JOSM for example) or manually. >> >> I disagree that a) it is not possible to sort such routes and >> b) that sorting doesn't help. >> >> A route that goes like this: >> >> A -> X -> B >> <- Y <- >> >> can be put into the relation in order A, X, Y, B or A, Y, X, B. >> Or to put it more formally: If you take only ways used to get from >> A to B, you should get a linear route. And if you take only ways >> that are used to get from B to A, you still get a linear route. >> >> You get a nicely sorted route with one break in there. It's easy >> to do in any editor where sorting is easy to do and there is no need >> for nested relations. >> >> To convert something like this into a linear geometry, do: >> >> 1. Go through relation and reverse all ways as necessary to create a >> route with minimal gaps. >> 2. For each way that is tagged forward/backward you can now determine >> from the direction of the way and its role if it is part of A->B >> or B->A. >> 3. Filter all ways that are two-way or marked A->B, line them up and >> you have one direction of the route. >> 4. Rinse and repeat for direction B->A. >> >> Or to put it in other words: you can use exactly the same algorithm >> as for linear routes and just add a bit of oneway detection on top. >> >> (I am aware that roundabouts are a special case that should be handled >> to spare the mapper splitting of roundabouts. But, again, if the route >> is sorted, then detecting this is a piece of cake, even when the >> roundabout is split at inconvenient places.) >> >> > Let me also introduce a further complication in the "sorting" discussion >> > for hiking and cycling route relations. >> > Some mappers like the idea to keep signposts in the same route relation >> as >> > the ways making up the route. This strategy has been adopted in an >> > important collaboration between the Italian Alpine Club (CAI) and OSM >> (in >> > Italy represented by WIkimedia Italia). Unfortunately the corresponding >> > wiki page <https://wiki.openstreetmap.org/wiki/CAI> is only available >> in >> > Italian. >> >> This is not relevant for sorting during processing. Those members are >> stripped >> away first thing. If it bothers you during editing, I have to say that I >> have >> little sympathy as those guideposts don't belong into the relation in the >> first place. Use >> https://wiki.openstreetmap.org/wiki/Relation:destination_sign >> instead. >> >> Sarah >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
