Feature - Alter Bicycle Routes with the Use of the Cursor

[grant-humphries]

This feature will allow you to grab the route at any point with the cursor and alter that route by dragging it to a point that you wish it to pass through, as is possible with google's bicycling directions. This allows the user to avoid obstructions or undesirable areas that they know about, but that are not in our data. In addition cyclists can model the exact route that they take between two places by modifying the trip generated by OTP which will allow them to determine the distance of their route and to compare that to the trip that the trip planner gives them.

Info on Google's Implementation: Google allows an unlimited number of additional points to be added to the route through this method and an "undo" link appears above the map once the route has been altered that will return the trip to its original form when clicked. The added points appear as white dots on the route and can be removed by right clicking them and selecting "remove this point". When the cursor is hovering over the route a dialog box appears that says "drag to change route" and a white dot appears on the route showing exactly where you'll be grabbing it and that you can slide along this path with the cursor.

[barbeau]

+1, we've had feedback in Tampa that this would be very useful for bicyclists, as well as other modes when you have local knowledge of something you want to avoid that isn't captured in the trip planner.

Andrew and I also talked about the same underlying technology supporting dynamic client re-routing for the real-time navigation feature on the mobile OTP app, when the user is off-route. Both dragging the route on the web client UI and handling dynamic mobile rerouting based on real-time position have similar requirements of efficiently recomputing portions of the route on-the-fly.

On Thu, Sep 15, 2011 at 5:17 PM, grant-humphries < reply@reply.github.com>wrote:

This feature will allow you to grab the route at any point with the cursor and alter that route by dragging it to a point that you wish it to pass through, as is possible with google's bicycling directions. This allows the user to avoid obstructions or undesirable areas that they know about, but that are not in our data. In addition cyclists can model the exact route that they take between two places by modifying the trip generated by OTP which will allow them to determine the distance of their route and to compare that to the trip that the trip planner gives them.

Info on Google's Implementation: Google allows an unlimited number of additional points to be added to the route through this method and an "undo" link appears above the map once the route has been altered that will return the trip to its original form when clicked. The added points appear as white dots on the route and can be removed by right clicking them and selecting "remove this point". When the cursor is hovering over the route a dialog box appears that says "drag to change route" and a white dot appears on the route showing exactly where you'll be grabbing it and that you can slide along this path with the cursor.

Reply to this email directly or view it on GitHub: https://github.com/openplans/OpenTripPlanner/issues/517

[fpurcell]

Any ideas on how to efficiently recompute the new routes on-the-fly while a control point is being dragged around the map? For the web UI, while the control point is held (clicked), the need is simply a new route geometry (and maybe elevation profile). No narrative is needed until the control point is released (after which, the full-on trip plan is submitted). In terms of dragging a control point around to find other transit options, I don't think that Google is doing anything more than giving street geometries with a heavy preference to return those street geometries to that have a transit line (well, maybe they're looking at the route patterns and the calendar of what service is available too, and not giving a preference if no current service is available).

It seems we need a separate api routine that can process multiple/repeated requests quickly, and only returns a minimal set of information. Looking at how Google does things, there's a different call while the map is being clicked, and the return is a geometry, a from/to reverse geo-code and a trip time estimate (which seems fairly accurate to the first trip itinerary they return (for transit)).

Thoughts on what (if any) new routing / apis work is needed to meet the original requirement above?

[pdxmele]

I think we want this more for bicycle-only routing (and maybe walk-only routing?) first off, while bike-transit can be sorted out later on. Looks like Google just adds another destination in the middle of the trip for the point you drag (I think I mentioned this at the conference), for example:

maps.google.com/maps? saddr=404+NE+Mirimar+Pl,+Portland,+OR+97232& daddr=45.50882,-122.64906 +to:4012+southeast+17th+avenue,+portland,+or+97202 &hl=en&sll=45.50962,-122.6396&sspn=0.050164,0.132093&geocode=FSiqtgIdx9Gw-Cl57OdqwaCVVDEBYZrwX_x13A%3BFdRotgIdHIaw-Cl954XLnaCVVDGh2V395cLekQ%3BFdkttgIdxYyw-CmrEva9hwqVVDF9HYFavWLXXw&vpsrc=0&dirflg=b&mra=dpe&mrsp=1&sz=14&via=1&t=h&z=14&lci=bike

[novalis]

For transit, this will be too computation-intensive. For bike-only, it seems like maybe caching the precomputed graph would work.

[grant-humphries]

I'm curious if the type of routing discussed in this article that novalis shared in the chat this week:

http://research.microsoft.com/apps/pubs/default.aspx?id=156567

will make this feature more viable (for biking and walking).

[novalis]

No, not for biking and walking. For walking, contraction hierarchies is actually safe (assuming it's non-broken), and might improve speeds. But for biking, I don't know of any viable speedup strategies. I'll give it some more thought though; there is an approximation which might make reach or arc flags viable.

[abyrd]

This level of interactivity represents significant development effort and is not currently a priority.