Long foot path

[ch33hau]

Hey there,

Recently, we encountered a couple of unusually long and winding footpaths, and we are seeking your advice.

Using the request below, europe.motis-project.de returns a suitable polyline to the destination, a distance of 292m. However, when we direct the same request to our server, the polyline is unnecessarily long, measuring 870m.

Interestingly, when the profile is set to bike, our server data returns a more accurate result of 220m.

Do you have any insights regarding this discrepancy?

We are using today's Germany data from OSM and the latest motis v0.12.9.

curl --location 'https://europe.motis-project.de/' \
--header 'Content-Type: application/json' \
--data '{
    "destination": {
        "type": "Module",
        "target": "/osrm/via"
    },
    "content_type": "OSRMViaRouteRequest",
    "content": {
        "profile": "foot",
        "waypoints": [
            {
                "lat": 52.479324,
                "lng": 13.351584
            },
            {
                "lat": 52.479934,
                "lng": 13.353464
            }
        ]
    }
}'

Thanks!

[felixguendling]

How does you config.ini look like? The route returned by MOTIS depends on the router you use. On europe.motis-project.de we're using the osr module (which currently does not support GBFS or park & ride yet, but this will be added in the future).

[ch33hau]

I don't have a config.ini but all the settings should be here:

motis \
--intermodal.router nigiri \
--modules address intermodal nigiri osrm ppr tiles parking \
--gbfs.update_interval 5 \
--import.data_dir /data/data \
--import.paths schedule-germany-latest-gtfs.zip:/data/import/gtfs/germany-latest-gtfs.zip osm:/data/import/input.osm.pbf \
--nigiri.debug false \
--nigiri.default_timezone Europe/Berlin \
--nigiri.num_days 93 \
--osrm.profiles /home/hunt/motis/osrm-profiles/bike.lua /home/hunt/motis/osrm-profiles/bus.lua /home/hunt/motis/osrm-profiles/car.lua /home/hunt/motis/osrm-profiles/foot.lua \
--ppr.profile /home/hunt/motis/ppr-profiles/default.json \
--server.static_path /home/hunt/motis/web \
--tiles.profile /home/hunt/motis/tiles-profiles/background.lua \
--num_threads 12

[ch33hau]

We didn't use osr (I just knew this module). But will this module affects osrm results? As you can see my curl request is using osrm module.

[felixguendling]

I guess the difference here is that europe.motis-project.de uses osr and you use ppr + osrm. But as you're also using GBFS and Park & Ride you can't yet switch to osr.

osr is acting as a drop-in replacement for osrm and ppr, mocking their APIs.

[ch33hau]

I see... yes we need GBFS and P&R too. Do you know when osr will be ready for them?

By the way, do you see this as a bug when we use osrm with foot walk from the blue mark to the yellow mark? Is it rather unusual though:

[felixguendling]

Yes, that looks definitely like a bug. Feel free to submit a fix to our version of OSRM:
https://github.com/motis-project/osrm-backend

However, our priority is to eliminate the OSRM dependency and use osr for all use cases (maybe with an option to add HTTP endpoints for routing if it does not require deep integration). For Park & Ride, we already have a implementation in osr (motis-project/osr#15). However, we found out that many parking places in OSM are not connected with a common node to the street network. So we need to introduce additional connections to make it work. This is our TODO list.

[ch33hau]

Yes, that looks definitely like a bug. Feel free to submit a fix to our version of OSRM: https://github.com/motis-project/osrm-backend

However, our priority is to eliminate the OSRM dependency and use osr for all use cases (maybe with an option to add HTTP endpoints for routing if it does not require deep integration). For Park & Ride, we already have a implementation in osr (motis-project/osr#15). However, we found out that many parking places in OSM are not connected with a common node to the street network. So we need to introduce additional connections to make it work. This is our TODO list.

Thank you for the insights!!

[ch33hau]

Yes, that looks definitely like a bug. Feel free to submit a fix to our version of OSRM: https://github.com/motis-project/osrm-backend

However, our priority is to eliminate the OSRM dependency and use osr for all use cases (maybe with an option to add HTTP endpoints for routing if it does not require deep integration). For Park & Ride, we already have a implementation in osr (motis-project/osr#15). However, we found out that many parking places in OSM are not connected with a common node to the street network. So we need to introduce additional connections to make it work. This is our TODO list.

Hi @felixguendling ,

We discovered that certain nodes (barrier=kerb; kerb=lowered and barrier=lift_gate) were blocking the footpath.

motis-project/osrm-backend#3

With adjustments to the foot profile, the routing now works much better (I left some examples in the PR). Please review this PR to determine if it is suitable for merging into the main branch.

Thank you!

[felixguendling]

I merged it. You can update the commit ref in MOTIS .pkg file and make a PR. Thank you!

[ch33hau]

Thanks a lot! #533

[ch33hau]

Thanks again for release it!