GNOME Bugzilla – Bug 698470
Implement routing
Last modified: 2014-04-23 00:10:09 UTC
Filing this as a place holder so other people can find my work so far ... https://github.com/jku/gnome-maps/tree/wip/osrm-routing contains my very preliminary OSRM-based routing code. It's missing loads of things, but can at least draw the route on the map already. Things to do before I think it's ready for merge: * button in mapLocation is a normal gtk button: make it fit the OSD style * create the route instructions sidebar * probably other things I haven't noticed yet Other notes / future work: * Think through how the routing is initiated: I think the current idea of using "user location" as the route starting point is good when that location is at least accurate to a few hundred meters: IP location is not useful as a starting point of a route. Also, getting route by choosing an arbitrary location on a map seems like normal use case to me. * route in general should be draggable, creating a new "viapoint" as result * viapoints should be presented differently from normal instruction points, and they need to be draggable (this includes end points) and deletable
A comment I forgot: * google maps (website) does not draw the instruction points on the route at all: a bubble only appears at the instruction location when you hover over the instruction on the list. This looks nice and clean, and may be worth copying.
Things to fix before merging: * Getting a long route will freeze Maps: maybe Champlain doesn't cope well with a layer with thousands of points... example is a route from Helsinki to Oslo: " JS LOG: Got a 991782m route with 6403 nodes and 90 turn instructions." Panning and zooming in on the route works fine, but the initial 6000 Champlain.PathLayer.add_node() calls take a long time. Notes on that: * before doing anything should see if there are easy ways to make champlain more efficient * Simplifying the polyline ourselves is fairly easy (see Douglas-Peucker). * We'd still want to use the accurate polyline when zoomed in close. * This could be a champlain feature if the speed can't be improved enough: store all the coordinates, but only render "useful" points, where useful is defined as: - is visible (or maybe close to being visible) in the view - douglas-peucker says the point is important at this zoom level As workaround for now, could just prevent extra long routes or maybe add the points in smaller batches in a idle handler.
(In reply to comment #2) > * before doing anything should see if there are easy ways to make champlain > more efficient Should have checked before writing all that: there is indeed a way to speed up champlain a lot: it invalidates the canvas 6403 times when the nodes are added...
(In reply to comment #0) > Filing this as a place holder so other people can find my work so far ... > > https://github.com/jku/gnome-maps/tree/wip/osrm-routing contains my very > preliminary OSRM-based routing code. It's missing loads of things, but can at > least draw the route on the map already. Cool! That was fast. :) I suggest putting this into our git.gnome repo under 'wip/' prefix so that you can force non-fastforward. I'll be able to comment on other points once I try it out. :)
> Cool! That was fast. :) You shouldn't have said that. Now I've been slacking for two weeks. Anyway: the code is in wip/osrm-routing in gnome git now. It's definitely WIP for now, but testable: Do a text search, click "Route to this location".
We have new routing code based on GraphHopper coming for 3.14.
(In reply to comment #6) > We have new routing code based on GraphHopper coming for 3.14. But this bug is still valid until that work is merged. :) If there is another bug for that, feel free to mark this as duplicate.
Unfortunately Mattias completely forgot that someone filed a bug from day one and created a new one, bug#728695. :) Since that has patches and reviews and stuff, I'd reluctantly make this one a duplicate.
*** This bug has been marked as a duplicate of bug 728695 ***