More API parameters

[ynerant]

Hi!

I think that the OpenAPI is missing some useful parameters for some queries. I am sure that you planned to add more later, but I didn't find anything related, so here is a (non-exhaustive) list:

• /geocoding:
  • Filter by type (address or stop)
  • Research is rather buggy for french addresses: I can't find my house for example. You can try to find the address "1 Rue de Rivoli, 75001 PARIS", which exists in OSM data (https://osm.org/node/703504406) but can't be found with MOTIS. This module is unusable for me at this time. This may need a separated issue.
  • To partially fix the previous problem, geocoding endpoint could take optional geometry parameters that describe the research box (like it's done in the /stops endpoint). This may restrict the research on this box, or prioritize it (I don't know how difficult it is).
• A /stop endpoint is missing I think, which could let fetch data on a stop point with its stop id. Currently, to get the name and the place of a stop, we need to call the /stoptimes endpoint.
• /stoptimes:
  • It is impossible for now to get the next arrivals. I am making a departure and an arrival board, and I want to display next arrivals. For now, we can only display next departures or last arrivals.
  • A route filter and a mode filter would be very nice to have, to be able to query next departures for a specific kind of route on a point (for example: next subways/trams/buses departures on a specific line or not).
  • This implies to know what routes have trips through this stop, which would be very nice to have, but quite difficult.

I am currently running the version v2.0.0-beta14.

[felixguendling]

• /geocoding:
  • Yes, filtering has been proposed also by others on the transitous or MOTIS Matrix channels (feel welcome to join us there btw. 😃). I just didn't have time yet to implement it. My main focus currently is on bringing MOTIS v2 to become a release candidate.
  • Currently, the geocoder requires the addr:street tag to be set on the node or way. This is the case here: https://osm.org/node/4416976889 So I would expect this node to show up (which is doesn't - I'll look into it). To match nodes/ways without addr:street, we would probably have to check which is the closest street and then add this info in the preprocessing. Quote from the OSM Wiki:

    Regardless, it is important to accompany addr:housenumber=* with addr:street=* to avoid ambiguity and keep geocoders from having to make potentially faulty assumptions.

  • True. Filtering to a bounding box and bias towards a coordinate is definitely on the wish list. It's the same problem as for the first point.
• I am not really sure what's your use case? All APIs provide not just the stop ID but also coordinates and name. Or did I miss something? But in principle it would be trivial to have an endpoint that takes a stop ID and returns a Place.
• /stoptimes
  • Maybe a direction=EARLIER|LATER parameter would help? If not set the behaviour stays the same as it's now.
  • Currently we don't have the concept of a "route" in MOTIS. So this would need some extra plumbing on the input pipeline + data model. Mode filtering would be possible though.

[felixguendling]

Update: beta-15 contains now two additional parameters for /stoptimes:

• mode: a list of modes which will be used to filter. Default is TRANSIT which is an alias for all transit modes. So the behaviour won't change if the API is used without the new paramter.
• direction: default is the same as before without any parameter. Otherwise it's used to give you the previous n events or next n events.

Let me know if it works.

[felixguendling]

moved to:

• feature: geocoder bounding box restriction #663
• feature: geocoder bias coordinate #662

closing here