No connections in response JSON

[1Maxnet1]

When I try to search for connections, my client creates e.g. this Request:

{
  "_type": "IntermodalRoutingRequest",
  "start": {
    "_type": "IntermodalOntripStart",
    "position": {
      "lat": 46.756,
      "lng": 7.606
    },
    "departure_time": 1723198712
  },
  "start_modes": [
    {
      "mode": {
        "_type": "Foot",
        "max_duration": 900
      }
    }
  ],
  "destination": {
    "_type": "InputPosition",
    "position": {
      "lat": 48.55429,
      "lng": 9.386918
    }
  },
  "destination_modes": [
    {
      "mode": {
        "_type": "Foot",
        "max_duration": 900
      }
    }
  ],
  "search_type": "Default",
  "search_dir": "Forward",
  "router": "",
  "allowed_claszes": [
    0,
    1,
    2,
    3,
    4,
    5,
    6,
    7,
    11,
    12
  ]
}

The server returns an 200 (so it seems okay, but the request does not include any connections. However if I try out the Web UI for these coordinates, it gives some connections. Any ideas what could be the issue?

[felixguendling]

I think this is a bug. Your starting coordinate is too far (>200m) from the street network, so the result of the foot routing is something like MAX_VALUE to indicate that it failed to find the footpath from the start coordinate to a public transit stop.

Both endpoints (PPR + OSRM) are implemented by the osr module.

However, for the FootPPR case (which is used in the demo UI), the numbers are devided by 60 here without checking for the case that the special value MAX_VALUE was returned. In case Foot mode is used, no conversion (multiplication, etc.) is necessary here.

So actually, returning no result (like it's the case for your query) is the correct result. The UI returning results with a 18h footpath is a bug because the footpath length should indicate "not possible" which seems not to be checked. My assumption was that the intermodal module filters this, but this seems not to be the case for PPR here.

Edit: so I think the correct way to handle this would be to check for the special MAX_VALUE in the OSRM response and then return a empty vector here.

[1Maxnet1]

I think this is a bug. Your starting coordinate is too far (>200m) from the street network, so the result of the foot routing is something like MAX_VALUE to indicate that it failed to find the footpath from the start coordinate to a public transit stop.

Thanks a lot for the answer. Is it somehow possible to set this value (200m) in the configuration for a MOTIS instance?

[felixguendling]

Currently not. The newest version of osr allows to set this parameter in the routing as a runtime parameter:
https://github.com/motis-project/osr/blob/a6481a502e35d2f017545325d17d9234db414574/src/route.cc#L443

However, MOTIS is not yet using the latest version of osr.

Currently, I'm focusing to create a new MOTIS version that simplifies everything and has a OpenAPI interface and a TypeScript based Svelte 5 UI (it's really pleasant to program!). The prototype can be found here. I'll move this repo over to the MOTIS repository as a 2.0-beta branch which will at one point (hopefully still this year) replace the master branch which will then be renamed to legacy. The repo started as a prototype for accessible wheelchair routing (which is easier to accomplish without MOTIS' strict module structure because so many data sources need to be mixed and matched for this use case) but I am aiming to replicate all of the MOTIS APIs in the coming months.

[1Maxnet1]

Thanks for the insights. I will check how to tackle the issue on my side then. 👍

[felixguendling]

Feel free to submit a PR to improve the situation in MOTIS :)

[1Maxnet1]

Feel free to submit a PR to improve the situation in MOTIS :)

Yeah, but first I need to figure out, how to make it work 😅

[1Maxnet1]

Follow up question:
I adapted my code to map the coordinates to the street network, by performing a reverse geocoding. Now start and aim are on the street network and again in the Web search I can get connections, but when I send the following request, there are no connections in the repsonse:

{
  "_type": "IntermodalRoutingRequest",
  "start": {
    "_type": "IntermodalOntripStart",
    "position": {
      "lat": 47.839134,
      "lng": 7.715423
    },
    "departure_time": 1723448056
  },
  "start_modes": [
    {
      "mode": {
        "_type": "Foot",
        "max_duration": 3600
      }
    }
  ],
  "destination": {
    "_type": "InputPosition",
    "position": {
      "lat": 48.374235,
      "lng": 8.088494
    }
  },
  "destination_modes": [
    {
      "mode": {
        "_type": "Foot",
        "max_duration": 3600
      }
    }
  ],
  "search_type": "Default",
  "search_dir": "Forward",
  "router": "",
  "allowed_claszes": [
    0,
    1,
    2,
    3,
    4,
    5,
    6,
    7,
    11,
    12
  ]
}

Note I needed to increase the foot routing time to 30 mins or more, to get a connection for this one.
Any ideas about further possible issues?

[1Maxnet1]

Thanks for the clarification. However I think this is in contrast to what the OpenAPI docs show: https://europe.motis-project.de/openapi/#/operations/intermodal
When I choose in the dropdown menu the IntermodalOntripStart, the min_connection_count option disappears, so I assumed I cannot use it together with IntermodalOntripStart.

[1Maxnet1]

When trying the adapted request with IntermodalOntripStart the server does now just give a MOTISError, not a repsonse:
Request

{
  "_type": "IntermodalRoutingRequest",
  "start": {
    "_type": "IntermodalOntripStart",
    "position": {
      "lat": 47.839134,
      "lng": 7.715423
    },
    "interval": {
      "begin": 1726064340,
      "end": 1726071540
    },
    "min_connection_count": 5,
    "extend_interval_earlier": true,
    "extend_interval_later": true
  },
  "start_modes": [
    {
      "mode": {
        "_type": "FootPPR",
        "search_options": {
          "profile": "default",
          "duration_limit": 900
        }
      }
    }
  ],
  "destination": {
    "_type": "InputPosition",
    "position": {
      "lat": 47.919529,
      "lng": 7.69927699
    }
  },
  "destination_modes": [
    {
      "mode": {
        "_type": "FootPPR",
        "search_options": {
          "profile": "default",
          "duration_limit": 900
        }
      }
    }
  ],
  "search_type": "Default",
  "search_dir": "Forward",
  "router": "",
  "allowed_claszes": [
    0,
    1,
    2,
    3,
    4,
    5,
    6,
    7,
    11,
    12
  ]
}

Response:

{
  "_type": "MotisError",
  "error_code": 4,
  "category": "motis::access",
  "reason": "access: timestamp not in schedule"
}

To me this does not seem to make any sense, as I copied the timestamp from a request of the Wb Frontend that worked there, so the timestamps should not be out of schedule.

[1Maxnet1]

Another point, with the first request I got one element in the connection part of the response, but this was only made up of one start and one end element, so there was not the needed information for me available.

[pablohoch]

For the destination, the lat and lng fields need to be included directly in the InputPosition - there is no position field.

With these class restrictions, it returns no results, but your request works with the position fix and without allowed_claszes:

{
  "_type": "IntermodalRoutingRequest",
  "start": {
    "_type": "IntermodalPretripStart",
    "position": {
      "lat": 47.839134,
      "lng": 7.715423
    },
    "interval": {
      "begin": 1726063309,
      "end": 1726066909
    },
    "min_connection_count": 5,
    "extend_interval_earlier": true,
    "extend_interval_later": true
  },
  "start_modes": [
    {
      "mode": {
        "_type": "FootPPR",
        "search_options": {
          "profile": "default",
          "duration_limit": 900
        }
      }
    }
  ],
  "destination": {
    "_type": "InputPosition",
    "lat": 47.919529,
    "lng": 7.69927699
  },
  "destination_modes": [
    {
      "mode": {
        "_type": "FootPPR",
        "search_options": {
          "profile": "default",
          "duration_limit": 900
        }
      }
    }
  ],
  "search_type": "Default",
  "search_dir": "Forward",
  "router": ""
}

[pablohoch]

Regarding the class restrictions: It looks like these connections need a bus (class 10), which is not included in your list of allowed classes.

The current list of class numbers can be found here: https://github.com/motis-project/nigiri/blob/d6e1c8f5c0a8264e568fa85a34622e105a975315/include/nigiri/types.h#L274-L289

[1Maxnet1]

Thanks for the elaborations @pablohoch I was able to fix my client with this. I didn't realize the allowed classes where optional.