Impossible to route in Milan (IT) to places only accessible by foot?

[Altonss]

It it impossible to route to Milan (IT), but directly to train stations there seems fine. This might be due to failing pedestrian routing? I can only reproduce in the area though 🤔

[jbruechert]

It could be that the center of the city is inside a building, which could cause this.

EDIT: Seems to be the case, moving the marker to the next street fixes it.

Generally we are missing the concept of "somewhere in that city" right now.

@vkrause Do you have some insight to how the DB hafas handles their caps aliases like "BERLIN" by any chance from your DB API implementation work in KPublicTransport? Is it just an alias do the central station?

[Altonss]

It could be that the center of the city is inside a building, which could cause this.

EDIT: Seems to be the case, moving the marker to the next street fixes it.

We should try to route to the closest point on the street (within a certain margin), to at least avoid crashing the whole routing. Because, otherwise, I suspect a lot of queries to "city markers" might fail too :/

[jbruechert]

Can you report this upstream please?

[Altonss]

https://github.com/motis-project/motis/releases/tag/v2.0.14 might fix this

[jbruechert]

Unlikely, we don't use osr_footpath (which is only about transfers)

[vkrause]

Do you have some insight to how the DB hafas handles their caps aliases like "BERLIN" by any chance from your DB API implementation work in KPublicTransport? Is it just an alias do the central station?

The all-caps locations do have coordinates internally ("BERLIN" e.g. is somewhere near Friedrichstraße), but the router does seem to special-case those, you definitely don't get routed to those coordinates. It's slightly more clever than making those just an alias to the central station though, e.g. when routing to "KÖLN" it gets you to either Köln Hbf or Köln Messe/Deutz. "PARIS" is another obvious example where it considers different stations.

I'm not aware of a way to query all possible stops it considers to be part of that (assuming this is even implemented as a fixed set of stops).

[felixguendling]

The behavior of all-caps stops is documented in the HAFAS Rohdaten documentation (e.g. here on page 69). In terms of GTFS it's a bit like having a second parent for all stops in a city which is the all-caps city name. Then, the router considers all those destinations as equal (simplified: wherever the router arrives first wins).

[felixguendling]

My guess is that this is the same problem as discussed on Matrix (MOTIS room):

---

Tobias Schwarz

Hello!
I'm playing around with the directModes for car routes. Since I don't want to spam the issues on github, another question in this channel:
I've testing a route from the center of two cities (Memmingen and Stuttgart in Germany) with this request:
/api/v1/plan?fromPlace=47.9863099,10.1808016&toPlace=48.7784485,9.1800132&directModes=CAR&transitModes=&maxDirectTime=720000&maxMatchingDistance=10000

Unfortunately I'm not able to get a route between these two places, even with maxDirectTime and maxMatchingDistance extremely high (but also not with reasonable values).

Both points are really close to streets!

Are these parameters working as expected?

Felix Gündling

I guess the coordinates start on "islands" - parts of the road network that are not connected to the rest of the road network.

With slightly changed coordinates, it works:
https://europe.motis-project.de/api/v1/plan?fromPlace=47.986029135472464,%2010.17965538120085&toPlace=48.775884461022635,9.18293102747148&directModes=CAR&transitModes=&maxDirectTime=7200&maxMatchingDistance=100

I started implementing a solution to this problem a few months ago but didn't have time yet to finish it.
Link to working branch: https://github.com/motis-project/osr/tree/way_components

The idea is to quickly discover connected components via a simple flood-fill algorithm. Then, every node and way is annotated with a component ID. This is done during the preprocessing, so there would be no additional runtime overhead.

Then during query phase, when resolving coordinates to graph nodes, we won't just select the closest (as it's implemented now). Instead we'll select one on the start side and iterate matches on the destination side until there's one that has the same component ID. If there's none within the maxMatchingDistance, we move to the next node on the start side and repeat until there's a match.

So that would probably solve your problem. Unfortunately, this takes a bit of time. Additionally, our street routing currently only implements Dijkstra's algorithm which is perfect for 1:N queries like the routing to nearby stops. For long distance queries it would make sense to at least use A* or even Multi-Level-Dijkstra / Contraction Hierarchies / Landmarks / etc. etc. Since this will take even more time, I would recommend to use something like OSRM, GraphHopper or Valhalla for long-distance queries until MOTIS/osr has those features implemented. I hope it won't take long :)

I'm not saying we won't get there.. it's just that we're not there yet. osr started as a fun experiment not even a year ago and turned out to be very promising in terms of low resource usage and potential regarding features like multi-profile routing, real-time support for traffic information etc etc. So it's quite fresh but we'll bring it to be on par with all the other pure street routers.