Just a word of warning: Since this is neither based on EFA nor on Hafas, it will be a serious undertaking to completely implement and maintain this. Are you willing to undertake this? Just out of curiosity, are you living in a area that is covered by search.ch?

A good way to prove and test functionality is by offering test cases. Please have a look at the other "LiveTest" classes, I recommend you to create such a collection of tests as well (both for straighforward queries, but also for edge and error cases).

Just a word of warning: Since this is neither based on EFA nor on Hafas, it will be a serious undertaking to completely implement and maintain this

Yes, (I think) I'm aware of the scope of this undertaking and I'm also willing to maintain this provider in the future (yes, I live in the area covered by search.ch 😉 )

Some technical questions:

• Delays are calculated by subtracting plannedArrivalTime from predictedArrivalTime?
• The class Position stores track information (e.g "Gleis 5, Sector C") and unplanned track-changes are "calculated" similarly to delays?
• What is the difference between the place and name - attribute in Location
• The message attribute in Trip.Leg is meant for storing special information (e.g Information about the cause of the delay)

And sure, after I get it working, I will provide a test suite.

* Delays are calculated by subtracting `plannedArrivalTime` from `predictedArrivalTime`?

* The class `Position` stores track information (e.g "Gleis 5, Sector C") and unplanned track-changes are "calculated" similarly to delays?

Yes, it's up to the user of this library how to present the difference to the user.

* What is the difference between the `place` and `name` - attribute in `Location`

It's a remnant of the EFA API. Place would be City and/or Part Of The City, Name would be the name of the station/stop. It's a bit fuzzy for non-station/stop locations, e.g. addresses. Afair, place is optional.

* The `message` attribute in `Trip.Leg` is meant for storing special information (e.g Information about the cause of the delay)

Messages are free-form. It could be anything textual you'd get from the server that would be useful to present to the user – e.g. the phone number to call for Bedarfsverkehr.

Hey @schildbach, a small question regarding the QueryDeparturesResult object: Its main data-structure is a list of StationDepartures which then holds a list of Departures, a Location and a List of LineDestination. How are these meant to be populated? A rough guess:

• Location holds the station of the "stationboard"
• LineDestination a set of all "available lines" with their destination
• Departures a list of all departures in the requested time-frame

Otherwise the implementation is already working in a rough state, I just have to wait for a major disruption to test more difficult cases ;)

Hey @schildbach. This implementation has gone through quite a bit of testing now - I think we can consider a merge. What do you think?