Multiple OSM files/regions?

[MTRNord]

Hi I was wondering: What is the correct way to have multiple regions in motis?

The config I tried is:

# Available moduels: ["adr", "gbfs", "intermodal", "nigiri", "osr", "osrm", "parking", "ppr", "tiles"]
modules=intermodal
modules=adr
modules=tiles
modules=osrm
modules=ppr
modules=parking
modules=nigiri
#modules=gbfs

intermodal.router=nigiri

[import]
paths=schedule-de:/input/schedule/latest.zip
paths=osm-de:/input/osm-de.pbf
paths=osm-dk:/input/osm-dk.pbf
data_dir=/data

[nigiri]
first_day=TODAY
num_days=31
default_timezone=Europe/Berlin
match_duplicates=true
gtfsrt=de|https://realtime.gtfs.de/realtime-free.pb

[osrm]
profiles=/motis/osrm-profiles/car.lua
profiles=/motis/osrm-profiles/bike.lua
profiles=/motis/osrm-profiles/bus.lua
#profiles=/motis/osrm-profiles/foot.lua

but that does not seem to generate any tiles for denmark.

I also tried merging it into a single file but that leads to ppr failing with bad_alloc after the serializing step.

[felixguendling]

I usually use the osmium command line tools and create an extract from the next bigger region containing all regions I need (in this case it's probably the Europe extract from Geofabrik). I create a very rough polygon using geojson.io and give this GeoJSON + the Europe OSM file to the osmium command line tool.

If you do not really need the parking module and have a SSD (no HDD), I would recommend to try it with this configuration and use the full European OSM data:

modules=intermodal
modules=adr
modules=tiles
modules=osr
modules=nigiri

[import]
paths=schedule-de:/input/schedule/latest.zip
paths=osm-de:/input/europe-latest.osm.pbf
data_dir=/data

[nigiri]
num_days=31
default_timezone=Europe/Berlin
match_duplicates=true
gtfsrt=de|https://realtime.gtfs.de/realtime-free.pb

I replaced ppr and osrm with our new "in-house" routing osr which requires way less memory.

We plan to add sharing support (GBFS) as well as parking support to osr, so osr will be able to fulfill all use cases.

[felixguendling]

Are you using an up-to-date GTFS-static dataset? It's possible that things like this happen if the GTFS-static dataset is not up-to-date and IDs change. But then, any journey planner (not just MOTIS) would have issues.

[felixguendling]

I set up the MOTIS instance as a server with automatic restart 1x per day (3:30 am): https://gtfsde.motis-project.de/

[MTRNord]

Are you using an up-to-date GTFS-static dataset? It's possible that things like this happen if the GTFS-static dataset is not up-to-date and IDs change. But then, any journey planner (not just MOTIS) would have issues.

hm its a few days old when I started to look into motis the first time. I hoped that in the 3 days timespan the gtfs file would have stayed recent enough but this certainly may be the root cause here.

[MTRNord]

I will take a look at this on the weekend when I got some time for it and try to get your the necessary data. I will first update the gtfs-static dataset to see if thats the cause.

[felixguendling]

I had now the same problem and it really seems to be that the feed does not use stable IDs. Almost all feeds try to use IDs that are somehow stable across different versions of the schedule timetable (GTFS static). This feed however uses just auto-incrementing IDs with no specific order. So if their server (gtfs.de) changes the GTFS-static file you have to update in the same second, otherwise your real-time timetable will be completely messed up. Other GTFS-static/GTFS-RT endpoints are not that problematic as most try to use a stable referencing scheme for trips and stops.