<div dir="ltr"><div dir="ltr">John Doe <<a href="mailto:music.kashish@gmail.com">music.kashish@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">06-Mar-2020 20:39:30 Peter Elderson :<br>
<br>
> > [...] Is it a significant burden to include a router with a renderer?<br>
> I wouldn't know. It seems strange to me that established routes have to be re-routed to display or use them. How can you be sure the re-created route is the one that is defined by the operator? Keeping as an example the city PT map.<br>
<br>
That is something that mappers/maintainers would have to test, as they already do. The difference is that the time and effort required to create and maintain the relation is greatly reduced.<br>
<br>
Tangentially, something that might help would be a validator for editors that checks if a route (whether defined by ways or as deduced by a router as we propose) matches user-specified GPS traces.<br></blockquote><div><br></div><div>That sounds even more odd to me... what if it doesn't match? Do we have authoritative gpx-es for routers? I may be out of my depth, but I think a route for the map is observed and registered, not computed between A, B, C etcetera. A route on the fly is a different thing. </div><div><br></div><div>Would it be an idea to make the route itself (the observed chain of ways) an optional member relation of the PT routing relation? With member role=route?</div><div><br></div><div>Of course I would like to have a routing routine built into the relation editor,  which can convert a survey gpx-trace to a route relation containing the closest chain of already mapped ways, that would make route maintenance much easier. (All kinds of routes, not just PT).</div></div></div>