Realtime departures for MetProvider (PTV network, Melbourne/Australia)

[pserwylo]

About two years ago support for realtime departures was added to the Melbourne bus network. I'd like to add support for it to public-transport-enabler, but wanted to get some feedback before continuing (having not contributed here before).

Here is some quick info about the situation:

• PTV uses an AbstractEfaProvider
• The XML response returned by their server does not seem to include realtime departure info
• The website does support realtime info

I see one main option, but am happy to be told otherwise:

• Implement it like how the AbstractHafasProvider includes jsonStationBoard to be called by its subclasses in queryDepartures() if required. This would involve:
  • Overriding queryDepartures() in MetProvider
  • Query the relevant end point which returns JSON data with stop information
  • Either try to get enough info from that JSON data to return the right data structure, or combine it with a call to the parent queryDepartures() and try to merge the data together.

So my main questions are:

• Does that seem reasonable?
• Is it particularly bad to send two HTTP requests in queryDepartures() if required?
• Should it be implemented like PR #41 which would result in a separate MetRtProvider that extends MetProvider, or should I just add it to theMetProviderdirectly? (My preference is to add it toMetProviderso that users of this library get access to realtime data without having to change their code to supportMetRtProvider`).

Thanks.

[schildbach]

Actually first I would check with them if they plan to include realtime data in their EFA. Because if they don't do that, they will never get proper journey planning based on realtime data. And it would save us from a lot of trouble.

I would assume the JSON feed does not nearly return enough data to completely replace the XML EFA station monitor. So two requests would be hard to avoid, and at the same time this introduces questions like what if one of the two fails? Do the station IDs match up beween the two systems?

For this reason, I would suggest starting with a subclass. I guess for most users it's actually a feature if they don't get the behaviour changed drastically, and replacing "new MetProvider" with "new MetRtProvider" seems rather trivial to me.

[pserwylo]

Thanks for the quick respons @schildbach. Appreciate your patience as I'm trying to figure out how to proceed.

I will get in touch with them and ask about the XML feed as you suggested. In addition, I'm happy to create a MetRtProvider class if need be, though I also see no problem with changing the behaviour of the existing one, so that it adheres closer to the NetworkProvider interface (e.g. queryDepartures() states in its documentation that it may provide realtime info, and it seems to me that anyone who makes use of a NetworkProvider would therefore take into account that info may be realtime or scheduled).

With regards to their XML feed, I note that they publish their own (what seems to me to be proprietary and unique) API:

• https://www.ptv.vic.gov.au/about-ptv/ptv-data-and-reports/digital-products/ptv-timetable-api/ (overview)
• http://timetableapi.ptv.vic.gov.au/swagger/ui/index (reference documentation)

Is this common among other transport providers? Or would you suspect that they are really just proxying one of the existing providers that is already supported by public-transport-enabler?

If it is in fact their own new API that is distinct from others, should it be treated like such by implementing an entire new MetRtProvider that doesn't extend AbstractEfaProvider at all?

Cheers.

[losuler]

I wasn't sure if I should open a new issue for this or not, but I thought I'd mention that MetProvider is no longer working. The app is throwing UnexpectedRedirectException errors since the journey planner no longer exists at http://jp.ptv.vic.gov.au/ptv/.

[schildbach]

Yes, they shut off their EFA. I still have some hope they revise their decision.