GBFS: deer Carsharing provider is not picked up for intermodal routing.

[1Maxnet1]

I wanted to try out which intermodal routing results MOTIS provides for carsharing integration, so I tried with a Baden-Württemberg wide GTFS dataset and OSM Dataset and the deer-Carsharing GBFS feed, which is part of the Mobidata-BW combined feed as well.

MOTIS-Version tested: 2.0.63

GTFS-Dataset source: https://www.nvbw.de/fileadmin/user_upload/service/open_data/fahrplandaten_mit_liniennetz/bwgesamt.zip

OSM dataset: from Geofabrik.de

config.yml:

server:
  port: 8080
  web_folder: ui
osm: baden-wuerttemberg-latest.osm.pbf
timetable:
  datasets:
    nvbw:
      path: bwgesamt.zip

gbfs:
  feeds:
    deer:
      url: https://api.mobidata-bw.de/sharing/gbfs/v2/deer/gbfs
tiles:
  profile: tiles-profiles/full.lua
street_routing: true
geocoding: true
osr_footpath: true

Log for motis server:

2025-05-07T14:12:03Z [info] [server.cc:162] [motis.server] listening on 0.0.0.0:8080
local link: http://localhost:8080
2025-05-07T14:12:03Z [info] [timer.cc:9] [scoped_timer] [gbfs::update] starting
2025-05-07T14:12:03Z [info] [timer.cc:9] [scoped_timer] [compute routing data for gbfs provider deer] starting
2025-05-07T14:12:05Z [info] [timer.cc:18] [scoped_timer] [compute routing data for gbfs provider deer] finished (2176.394ms)
2025-05-07T14:12:05Z [info] [timer.cc:18] [scoped_timer] [gbfs::update] finished (2319.997ms)
...

Examples:

1. Routing from Vaihingen/Enz to Calw:

Comment: There is a station at a close by shopping center (with a car available when during testing), but the routing does not use it. Therefore it uses a car at the end of the routing for 1 minute. I expected it to be faster to rent a car in Vaihingen Enz and give it back at one of the many stations in Calw

2. Routing from Hochdorf/Enz Keltenmuseum to Stuttgart-Möhringen

Again I'd expect the pure sharing or the sharing + public-transport to show up, as both is faster compared to pure public-transport. One option would be to use the Carsharing to Schwieberdingen close by and continue with Bus from there. Or directly drive to the Carsharing station in Möhringen.

[pablohoch]

Regarding example 1:

I expected it to be faster to rent a car in Vaihingen Enz and give it back at one of the many stations in Calw

MOTIS finds that direct connection (6 min walk + 37 min car sharing + 1 min walk) with maxDirectTime=3600 added to the API call. The default limit for direct connections is 30 minutes and can currently not be changed in the UI, so it's currently not possible to find this connection using the UI.

Regarding example 2:

In addition to the time limit (~36 min needed), we seem to also have a matching problem here. Moving the start and destination coordinates closer to a road (e.g. 48.88894406940713,9.003257941274455,0 -> 48.72824848231292,9.147265213307492,0) + maxDirectTime=3600 results in a 36 min direct connection (2 min walk + 28 min car sharing + 8 min walk).

For the sharing + public transport case: This is slower than the direct connection, so it is not shown when both are possible. Removing RENTAL from directModes in the API call and adding maxPreTransitTime=1800&maxPostTransitTime=1800 results in connections with car sharing at the start and destination like this:

(It's currently not possible to generate this query using the UI. However, you can open your browser's developer tools, copy the plan API call, adjust the URL parameters, copy the resulting JSON and then paste it into the UI tab - then the UI will show the results of that API call.)

[1Maxnet1]

Thanks for all the clarifications!

MOTIS finds that direct connection (6 min walk + 37 min car sharing + 1 min walk) with maxDirectTime=3600 added to the API call. The default limit for direct connections is 30 minutes and can currently not be changed in the UI, so it's currently not possible to find this connection using the UI.

Does the limit speed up the routing? From a user perspective I do not think a maxDirectTime is actually a thing I would want to set, but as long as it can be set in the API call, this is fine of course.

[felixguendling]

Does the limit speed up the routing?

Yes, definitely.

osr (our routing) is ~1 year old now and we didn't have time yet to implement more than a simple Dijkstra with only one stopping criterion (time) because that's what MOTIS needed the most at the beginning.

I do not think a maxDirectTime is actually a thing I would want to set

You're right. Me neither. I don't want to set any of these max*Time settings (maxPreTransitTime, maxPostTransitTime, maxDirectTime). That's the task of the router to determine which stops actually make sense to route to. Both, the set of stops to route to for first and last mile as well as the maxDirectTime are part of the solution and should not be part of the problem statement (aka routing query).

• maxDirectTime: We're working on it. This can be improved with A* / bidir A* which we have a basic implementation for already (A* + BiDir A* osr#32). However, I didn't have time to play with it and integrate it in MOTIS.
• maxPreTransitTime / maxPostTransitTime: here, a "smart mode" would make sense that routes to maybe the 10 closest nearby public transit routes and then (at least for bike/car) to the top 5 closest larger stations (or long distance public transit routes). This requires probably a lot of fine tuning.

Another problem especially for P&R car routing is that in most cases the routing will drive as much of the distance as possible (maxing out maxPreTransitTime) with the car as it's faster than the bus. However, this does not account for the environmental impact. So what would maybe make more sense here is to deliver the most relevant points of the Pareto-front with regards to optimization criteria driving time, total travel time, and transfers. This can be achieved by routing several times with different maxPreTransitTime and then afterwards mixing the results. Alternatively, a McRAPTOR implementation would also help (if we can make it fast for transitous.org scale datasets).

[felixguendling]

I opened #865 to address the remaining issues.

[felixguendling]

Moving the start and destination coordinates closer to a road

TODO: Investigate why.