-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update wiki with architecture relevant info: Draw routes using a navigation service #304
Comments
For the frontend, there are many libraries for connecting to a backend navigation service. For leaflet, this seems the most popular and with a relevant license: https://github.com/perliedman/leaflet-routing-machine . There are also navigation libraries that calculate everything in the frontend. I have not found polished libraries fitting our requirements easily. Note: "Public transport routing" in the context of navigation services is a different concept and requires different algorithms. It is what Digitransit does and I do not foresee any use for such functionality in Jore4. |
I suggest we do not treat the intermediate navigation locations in the UI as something relevant for the data model. They do not have to be junctions, stops or important points, for example. The intermediate locations are only needed to draw the route geometry and can be thrown away once the route geometry is finished and committed. |
On the backend, OSRM and Graphhopper are popular navigation engines. For either of them, I presume we "only" need to feed it data or reveal it our data sources, configure it and run it in Kubernetes. OSRM has up-to-date Docker images: https://github.com/Project-OSRM/osrm-backend#using-docker Graphhopper seems to require building our own Dockerfile but probably we can copy it from what existed previously: graphhopper/graphhopper#2004 |
The frontend side of this issue has a dependency on #26. |
Notice that with this approach, the frontend might not need to know about the topology of the infrastructure network when creating the route. E.g. making sure that "can't turn right here" is respected belongs in the backend where the data model has that information. Choosing traversing directions of the route on the infrastructure links becomes unnecessary in the frontend as well. (When the user creates new infrastructure links, the frontend would ideally allow the user to mark up the topology of those new links. The parts that HSL has to draw themselves are small and often at the edge of existing infrastructure network, though, so those parts do not have to be perfected before a Digiroad import overrides them.) |
|
Notify also the case of editing the drawn route. Card #430 |
Sample case presented in the MVP meet (starts at 2:21) https://drive.google.com/drive/u/0/folders/1aT08ubZv0KfqX5dRjhDDpPwNkP_yocDF Esimerkki case, jota voi tässäkin harkita lähtökohtana: HSL:n reaaliaikaisessa liikenteenhallintaohjelmassa voi tehdä poikkeusreittejä. Sen toimintalogiikka: klikataan oikealla pysäkkiä mistä poikkeusreitti alkaa, sitten valitaan mihin pysäkkiin se päättyy. Jos näiden pysäkkien väliltä löytyy reittejä - niitä ehdotetaan käyttäjälle. Jos niitä ei löydy, sen voi piirtää itse. |
As a public transport planner, I would like to draw routes with little effort and high accuracy so that creating routes is easy and quick.
Unlike Jore3, Jore4 will have a coherent infrastructure network. It is common in map applications to rely on that infrastructure network to create travel itineraries with navigation services such as Google Maps.
We can use the same methodology for quickly and accurately drawing routes. Instead of navigating just from A to B, we can force the route to go through some locations in between.
(Navigation services are commonly called routing services but let's avoid overlapping terminology.)
Image for illustration only (from https://github.com/Turistforeningen/leaflet-routing ):
![illustration](https://camo.githubusercontent.com/1df716700037d64b8a3591689b3dc55d01b501133dd7db21e4d489881cc9339d/68747470733a2f2f7261772e6769746875622e636f6d2f547572697374666f72656e696e67656e2f6c6561666c65742d726f7574696e672f67682d70616765732f696d616765732f70726f6d6f2e676966)
Example demo UI (with a bit of a poor support for intermediate locations though the engine can handle it): https://map.project-osrm.org/?z=13¢er=60.181264%2C24.971752&hl=en&alt=0&srv=1
The text was updated successfully, but these errors were encountered: