Recommended / standard way to dynamically specify platform of departure (on a daily basis)

[Bodo Minea]

Hello everyone,

I am administering several GTFS feeds in my country and I am encountering a little dilemma.

I am creating a brand new GTFS feed for a ferry company. Most of the stops are single defined static points, hard-coded to a trip, like a single bus stop. But the main terminal base in the biggest city served by this ferry service is comprised of multiple boarding docks, in between which the walking distance can exceed 200 meters, like a big terminal train station or airport let´s say.

For the first iteration I will just define the waiting area with the information panels as the station, but in a subsequent improved version of this system I am aiming to direct people to the respective boarding dock. The problem is that the information isn´t static. Any trip may board from any dock, and the information is defined each morning by the port authority and handed out to the operator.

How would this be solved „by the book” with GTFS?

What I am thinking is:

• let the static GTFS trips be defined with the main station ID (the original one from the initial feed)
• create sub-stops of the main station with platform_code defined
• use GTFS real-time stop time updates to „replace” the sequence 0 departure with the according stop_id of the dock sub-stop. The information will be entered in a custom app that will output it as a tripUpdates protocol buffer feed.

Would this work? Is this something that GTFS consumers understand and handle (OpenTripPlanner, Google Maps Transit etc.), either in this or another way?

Thank you very much for your time and understanding and I am looking forward to hearing your input.

[Stefan de Konink]

On Saturday, August 1, 2020 5:27:26 PM CEST, Bodo Minea wrote:
> What I am thinking is:
>

> - let the static GTFS trips be defined with the main station ID (the

> original one from the initial feed)

This is the thing that I would consider the 'best' approach, but this is
*not* supported by the current specifications

> - use GTFS real-time stop time updates to „replace” the sequence 0

> departure with the according stop_id of the dock sub-stop.

I would go for a fixed station assignment (platform under a station) and
update it with the correct platform.

> Would this work? Is this something that GTFS consumers understand and
> handle (OpenTripPlanner, Google Maps Transit etc.), either in this or
> another way?

OTP would even understand a completely different stop. Google limits it to
a stop under the same station.
--
Stefan

[Stefan de Konink]

On Saturday, August 1, 2020 11:17:08 PM CEST, Bodo Minea wrote:
> *I would go for a fixed station assignment (platform under a station)
> andupdate it with the correct platform.*
>
> Thank you for your answer. But according to discussions I had on the
> MobilityDataIO Slack channel that directed me to this issue -
> https://github.com/google/transit/pull/219 there is no way currently to
> specify the platform dynamically, it is debated whether it should be added
> and if yes, in what form/structure.

I didn't know that MobilityData was the authority on providing data dynamic
data. You have been wrongly informed. Your use case; switching between
multiple stops under a *same* station structure is supported in the past 7
years by *all* major players. MobilityData has an agenda to change the way
how this is provided in GTFS-RT.



> So the fact that the only spec'd way to do it is under discussion would
> mean that there is NO way to do this in real time at the moment and nobody
> is doing it? (looking especially at the platforms shown for the Thameslink
> and other services around London, it would be strange to learn that those
> are purely static GTFS as they're pretty much dynamic at station level).

We are doing it all the time. For every track change. And it is visible on
Google Maps. But it is great to know where fake news comes from.


Leo/Sean: spreading this kind of BS is hurtful.

--
Stefan

[guillaume...@gmail.com]

Stefan, 

I responded to Bogan directly on Slack simply by sending him directly to the GitHub discussion and he got the information from there which you know all about. There is no BS, no fake news, just sharing information. 

[Stefan de Konink]

In terms of just sharing information. The statement "there is no way
currently to specify the platform dynamically" is invalid. Below is the
original (and functional) proposal (by Google) to exchange track changes
since 2015.


GTFS feed

stops.txt

1- Add an entry within stops.txt representing a station with unique
stop_id, location_type set to 1 and parent_station blank. We support
realtime platforms change within single station only.

2- indicate all platforms as stop_ids, with location_type set to 0 and the
stop_id of the corresponding station in the parent_station field. All
possible platform in the station should be included in stops.txt in order
to be used in trip_updates to indicate the platform information in real
time.


Example:

stops.txt:

stop_id, location_type, parent_station, platform_code ...
stationA, 1, , , ...
stopA-1, 0, stationA, 17,...
stopA-2, 0, stationA, 18,...
stopA-3, 0, stationA, ,...


stop_times.txt:

trip_id, stop_sequence, stop_id, ...
trip-1, 1, stopA-1, ...
trip-1, 2, stopB, ...
trip-1, 3, stopC, ...



GTFS-RT feed

Platform changes could be specified within GTFS-RT feed. stop_id selector
nested in StopTimeUpdate allowed to be set to any stop_id within station
this StopTimeUpdate is referring to. Example:

entity {
id: "entity_id"
trip_update {
trip {
trip_id: "trip-1"
}
stop_time_update {

stop_id: stopA-2

stop_sequence: 1 # Optional
arrival {
time: 1284458072
}
}

...


Hint, using stops with not specified platform when the platform is unknown:

Stops with empty platform code could be useful to represent yet unknown
platform e.g. stopA-3 in stops.txt above.

Both GTFS and GTFS-RT could refer to such stop to indicate that the trip
stops in the corresponding station, at a platform which is currently still
unknown.

[gag...@google.com]

https://github.com/google/transit/pull/219 is the proposal to discuss how the platform changes should be handled in GTFS-RT to make it clear and unambiguous.

Currently the platform change is handled via GTFS-RT TU feed as described by Stefan. I agree that this is not documented but stops (platforms) within the same parent station can be updated via TripUpdate feed (as handled by Google Maps):

The following needs to be done in order to update the platform using TripUpdate feed:

- The static feed should create both physical platforms with relevant platform codes (e.g. "1", "2", "3" etc)

- The static feed can also add a "virtual" stop without a platform code and assign a trip to it if the platform code is not known in advance.

- The realtime TU feed should reassign the trip to the specific platform once the platform becomes known.

[Bodo Minea]

I am sorry that my question has sparked such intense discussions on not necessarily technical terms.

I am glad that I finally know that there is a solution that is not up to spec but currently in use and understood by at least one major consumer (Google Maps) and to be fair it's exactly the solution that I was thinking about and makes perfect sense for me, and there is also a proposed extension to the GTFS-RT standard to bring more features to said subsystem.

I will be implementing the current method as described by Stefan and when the other method becomes official and the protocol buffer bindings become available for it I will also be supporting the new spec.

Thank you very much for your time and implication.

--
You received this message because you are subscribed to a topic in the Google Groups "GTFS-realtime" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gtfs-realtime/M8OT623CK_Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/9c296f00-eab1-4ecb-b6a7-c59b49a87576n%40googlegroups.com.

--

Cu stimă,

Minea Claudiu Bogdan

(+40) 722 992 306

https://www.linkedin.com/in/mineabogdan

https://www.facebook.com/b0dominea