New Capability: VIA and REALTIME

[grote]

Hi @schildbach,

Navitia does not support Via for trip planning and they don't intent to do so (CanalTP/navitia#1589). Maybe we should introduce a VIA capability and set it to false for all Navitia based providers. What do you think?

While we are at it, how about a capability for providers that provide real-time data for delays? When they don't, options such as reloading a connection can be disabled/removed.

Kind Regards, Torsten

[schildbach]

A "via" capability sounds like a good idea to me.

What's the difference between being able to tell delays and realtime?

[grote]

A "via" capability sounds like a good idea to me.

Do you want to add this, or should I prepare an MR?

What's the difference between being able to tell delays and realtime?

Transportr for example lets you reload a trip to get current delays. I would hide this option for providers that do not provide delays anyway. The name for that capability could be REALTIME or PROVIDES_DELAYS.

[schildbach]

Sure, please go ahead (-:

What does reloading a trip mean? Pte doesn't have an API for this, no? Don't get me wrong, I just want to understand the semantics exactly.

[grote]

What does reloading a trip mean? Pte doesn't have an API for this, no?

PTE does have no API for it, but I just do another trip query for exactly the trip to be reloaded and then pick it from the result set and refresh the display.

[grote]

@ialokim in case you are bored, this ticket is a low hanging fruit and would help with Navitia-based providers that don't respect VIA locations.

[ialokim]

Haha, okay I'll look into it.

[ialokim]

There could be cases where delays are provided e.g. on the departures endpoint, but not while querying trips. Currently this seems to be the case for AbstractHafasLegacyProvider using the XML endpoint (?),

Perhaps we should add two new capabilities DEPARTURES_REALTIME and TRIPS_REALTIME. Any opinions on this?

[grote]

I only have a use-case for trip realtime and I guess the legacy provider will go away at some point, but would refer to @schildbach for a decision.

[schildbach]

The realtime capability is more complicated, it usually depends on the line (or even the specific car/train). Also, sometimes the realtime info is missing entirely for a given provider.

So for now, from this issue I'd only consider the VIA cap.

[ialokim]

it usually depends on the line (or even the specific car/train).

Sure, the capability would not express that there is real-time data for every single line or even train, but that there could be some (because it is provided by the endpoint and handled by pte), so that it makes sense to offer a reload functionality.

Also, sometimes the realtime info is missing entirely for a given provider.

That would be the exact use case we would cover with this (or these) realtime flag(s). I've already checked and it seems realtime is not handled by navitia nor by one or two custom providers, but it is handled by default in the efaProvider and hafasProviders. Not sure if there are some endpoints using hafas or efa which do not provide real-time data, in these cases the method hasCapability should be overridden.

I've already implemented both of the flags but if you want I could reduce the PR to the VIA capability.

[schildbach]

Yes, please at least separate commits.

[grote]

For the record: Identifying providers that will definitely not report real-time information would be sufficient for me.

[schildbach]

@grote For that, we'd need "negative capabilities", so e.g. NO_REALTIME.

[ialokim]

Honestly I don't quite see the point of such a "negative capability" which seems a bit counter-intuitive. Why not adding the REALTIME capability and returning true for hasCapability(REALTIME) in all providers as a default, and ensure it will return false for the ones that do not provide realtime information?