Metro-North Railroad GTFS RT Extension request

[John L]

MNR would like to add track to the StopTimeUpdate in the form of

message MnrStopTimeUpdate {

  optional string track = 1;

  //can add additional fields here without having to

  //extend StopTimeUpdate again

}

[Brian Ferris]

Let's go ahead and reserve extension id 1005 for Metro-North Railroad.

John, are you the appropriate contact for questions about this going forward?  (aka can I list your email on the extension page?)  If you have a general developer mailing list or website that you'd like to mention, that'd work as well.

--
You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/CAN3pBF6KuoV%3D7OF5b8Vzt714KoLABs0iLDkAeOUAx3kC1jsYGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jorden Verwer]

What is this about? Could you give me and others some more context, please? Thanks in advance!

Regards,

Jorden

[John Larsen]

Yes I would be as well as David Brenner

[John Larsen]

Also, mnra...@mnr.org but please use the subject line of GTFS or GTFS RT as this account is used for google play as well.

On Friday, May 8, 2015 at 4:12:21 PM UTC-4, Brian Ferris wrote:

[John Larsen]

Hi Jordan,

The state of Connecticut asked that MTA Metro-North Railroad provide track as part of the trip update. As this is not a part of the feed specification, an extension is needed and this is the request for that extension Identifier.

[Jorden Verwer]

Hello John,

My apologies for taking so long to reply, but what do you mean by "track"? Is this the physical track the vehicle moves on? If so, how is this useful information, given that we can already distinguish between different platforms in a station by using different stops and a single parent station? A change of platform would be a change of stop, for the GTFS-RT feed. I realize the means for communicating a change in stop sequence is currently being debated, but unless I don't understand you correctly I don't see how your use case is any different.

Regards,

Jorden

Op woensdag 20 mei 2015 03:05:39 UTC+2 schreef John Larsen:

[John L]

The arrival/departure track of the train at the station.

Thinking larger for the overall specification, this could be bay (buses), gate(various), ramp(various), dock(ferries), platform (various), track (rail).

A stop as you describe would be a marriage of the scheduled location and the schedled track. At Metro-North, there are currently about 137 stops with atleast 4 tracks plus Grand Central terminal with 42 tracks. In total, that would grow the GTFS stops.txt to 590. Plus another 137 for no track assignment to 727 stops. Nevermind that 5 stops will have the same index in the shapes.txt. This would also be a different business process as the stops never change (unless cancelled)  but the tracks do. There is also no documentation that states that a stop requires the metadata of track, platform, bay, etc.  to be in the text of the stop name. In fact , it states "The stop_name field contains the name of a stop or station. Please use a name that people will understand in the local or tourist vernacular."
When planning trips, "Grand Central Terminal Track 117" to "New Haven Union Station Track 3" will yield no results. Frankly, in my opinion, that is not a normal form for a data structure.

Bottom line, a trip is made up of stops, not tracks, platforms ramps or bays. This is important on the day of travel, hence the need to add it for the realtime feed and not the schedule feed.

On your website, I looked for a trip from Monchengladbach to Koln at 0127, oddly, there we no tracks or platforms in the station selection. When I selected a trip, there were no track assignments either. There seems to be 6 tracks at Monchengladbach and 10 tracks at Koln.

--

You received this message because you are subscribed to the Google Groups "GTFS-realtime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-realtim...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-realtime/f0b34416-259d-42ca-9b72-2b4801cbd5fc%40googlegroups.com.

[Jorden Verwer]

I understand your concerns a little better now. For this reason, some people use GTFS extensions that allow the platform name to be specificied as a separate field for a stop. In fact this may have been proposed for standardization, but I'm not sure. Indeed it's useful to be able to differentiate between the name of a station as people will generally understand and the name of the specific location where the vehicle will be located. In my view that's what the stop => parent station hierarchy is for. Applications are able to display the name of the parent station along with (or in lieu of) the name of the stop itself, if they so desire.

Generally, riders will formulate plan requests in terms of what GTFS calls parent stations but expected the resulting itinerary to contain individual stops. If you think the current model is flawed, I would prefer that we address your concerns directly instead of adding another level of hierarchy that only exists inside GTFS-RT. Many transit agencies do publish platforms/tracks as part of their schedule and in fact I would say this is the preferred modus operandi.

Any other opinions?

Regards,

Jorden

Op vrijdag 12 juni 2015 15:45:17 UTC+2 schreef John Larsen:

[John L]

I think the parent station works well for mixed environments.  For instance, Grand Central could be the parent stop fro Grand Central Terminal for Metro-North Railroad, Grand Central Terminal for Long Island Rail Road,  Grand Central Station for NYCT Subways and 42nd Street at Park Avenue South for NYCT Bus.

We will be using an extension for the GTFS RT and have been assigned an extension number.

The stops dictate the list of available stops on routes in planning applications. Stating that Grand Central Terminal as the parent station and the 42 tracks as it's children seems tedious as this could and does frequently change. I would suppose that each stop would have a parent and a child even if it were just one track to follow the pattern. That would make it clear to use parent stations for the list of stops for planning trips.
Besides, I think the intent of the parent station was to aggregate disparate transit modes in one area to link them together as described above.  It will work the way you state it but the specification does not state that it is or isn't intended for this or that usage.

Cheers!

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/_sEV6_60AsM/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/49ab4845-27a9-43e7-b354-0283a975b08a%40googlegroups.com.

[Jorden Verwer]

As long as this is just an extension and never becomes official, I suppose it doesn't hurt anyone. For the record, I disagree with your interpretation of the specification and how parent stations are supposed to be used.

Regards,

Jorden