Add new VIA and REALTIME capabilities

[ialokim]

This PR adds three new capabilities for network providers:

• VIA for providers that allow specifying a location to pass by
• DEPARTURES_REALTIME for providers that support real-time data on departures
• TRIPS_REALTIME for providers that support real-time data on trip queries.

As discussed in #95, the new capabilities are split into different commits.

Fixes #95.

[ialokim]

@schildbach: Would be cool to include this in PTE. Do you have any comments? I would rebase the PR if you are willing to look into it.

[schildbach]

VIA would be nice to have, yes. Shouldn't it be named TRIPS_VIA though, as it's a sub-capability of TRIPS?

[ialokim]

Shouldn't it be named TRIPS_VIA?

Good point, I will change that. What are your points against the REALTIME capabilities?

[grote]

For Transportr, only TRIPS_REALTIME would be interesting.

[ialokim]

I've rebased onto current master and changed VIA to TRIPS_VIA. Would be great if you could check it out @schildbach.

[schildbach]

@ialokim A provider-scoped realtime indicator feels redundant to me. Most providers indicate realtime by providing prognosed/predicted arrival and departure times. If I remember right, some indicate realtime on a per-line basis too (we don't expose that via API yet).

The usecase that was depicted in #95 by @grote could perhaps better be suited by adding a Trip.hasRealtime() which goes through all the stops and returns true if any of the predicted fields are set.

[ialokim]

The usecase that was depicted in #95 by @grote could perhaps better be suited by adding a Trip.hasRealtime() which goes through all the stops and returns true if any of the predicted fields are set.

I agree, that could be another solution, but I'm not sure what would happen in the case a provider does not have real-time information when querying for the first time, but later does have it (I've seen this case quite frequently in my region e.g. if a bus hasn't registered into the system before starting its journey). Trip.hasRealtime() would then return false and Transportr would hide the refresh functionality even if the provider could provide real-time data later.

On the contrary, no provider based on Navitia provides real-time data, so in these cases it would make sense to hide a refresh functionality for the whole provider.

[ialokim]

@schildbach Any more thoughts on this?

[ialokim]

Closed in favor of #333.