HSLdevcom / jore4

Public transport registry
European Union Public License 1.2
4 stars 2 forks source link

Update wiki with architecture relevant info: Draw routes using a navigation service #304

Closed haphut closed 2 years ago

haphut commented 3 years ago

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

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&center=60.181264%2C24.971752&hl=en&alt=0&srv=1

haphut commented 3 years ago

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.

haphut commented 3 years ago

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.

haphut commented 3 years ago

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: https://github.com/graphhopper/graphhopper/pull/2004

haphut commented 3 years ago

The frontend side of this issue has a dependency on #26.

haphut commented 3 years ago

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.)

haphut commented 3 years ago

pgrouting is an extension for PostgreSQL that can do navigation. It is available in Azure Database for PostgreSQL Single Server but not on Flexible Server at the moment. I have not found any roadmap for the development of Flexible Server. Flexible Server is still in preview, so maybe pgrouting will be supported in the future. One can vote to ask Microsoft to support pgrouting in Flexible Server: https://feedback.azure.com/forums/597976-azure-database-for-postgresql/suggestions/41604061-pgrouting-for-flexible-server.

ellinooraikaheimo commented 3 years ago

Notify also the case of editing the drawn route. Card #430

ellinooraikaheimo commented 3 years ago

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.