plan: START and END place seems to be reversed when searching with arriveBy=true

[mlundblad]

When doing a coordinate-based query setting arriveBy=true, it looks like the start coordinate place is labelled END and the arrival is labelled START:

Sample query:

https://api.transitous.org/api/v1/plan?fromPlace=50.849516050000005%2C4.367312985278861&toPlace=50.8140554%2C4.3841294&arriveBy=true&time=2025-02-01T07%3A30%3A00Z

[felixguendling]

True. The stop name here is more an implementation detail.
It's labeled by where from where to where the search goes.
The search starts at the destination (START) and ends at the origin (END).
In the end, I would expect the client to replace the name of the first+last stop with whatever the user entered, no matter what the name has been before (calling some kind of reverse-geocoder in case of coordinates).

[mlundblad]

True. The stop name here is more an implementation detail. It's labeled by where from where to where the search goes. The search starts at the destination (START) and ends at the origin (END). In the end, I would expect the client to replace the name of the first+last stop with whatever the user entered, no matter what the name has been before (calling some kind of reverse-geocoder in case of coordinates).

Yeah, I noticed this when checking some "arrive by" routes in GNOME Maps. In the normal case we substitute with the original query name (so it would be the searched name, or the raw coordinates if the user clicked on the context menu "Route from here/to here".

I think probably we should just change the logic so it replaces either START or END for "from" in the first leg (when non-transit) and for "to" in the last leg (when non-transit).