Removal Proposals: TripDescriptor.ScheduleRelationship = REPLACEMENT and description of StopTimeUpdate.ScheduleRelationship = SCHEDULED

[Chiara Micca]

Hi all,

Following a recent discussion on this group, I’d like to formally propose the removal of two parts of the current GTFS reference:

1- From the description of StopTimeUpdate.ScheduleRelationship = SCHEDULED, the sentence:

"An update with only an arrival, say, where the schedule has both, indicates that the trip is terminating early at this stop."

Specs reference : https://developers.google.com/transit/gtfs-realtime/reference?hl=it#ScheduleRelationship_StopTimeUpdate

Reason for removal: agencies often do have only either departure or arrival without wanting that to represent an early termination.

2- The current TripDescriptor.ScheduleRelationship = REPLACEMENT

Specs reference: https://developers.google.com/transit/gtfs-realtime/reference#ScheduleRelationship_TripDescriptor

Reason for removal: the current description is ambiguous and can be removed while we work on a better representation of similar use cases.

Any comments, feedback or questions on this?

Thanks!

Chiara

Partner Technology Manager - Google Realtime Transit

[Stefan de Konink]

On Tue, 8 Apr 2014, Chiara Micca wrote:

> Reason for removal: agencies often do have only either departure or arrival
> without wanting that to represent an early termination.

I do not agree with your reason for removal. I do agree with the removal
itself. My proposal:

The ability to cancel the end of the trip leads to two different
implementations for the same functionality. Secondary it is common that
only a departure or arrival is known.

Stefan

[Jorden Verwer]

Hello,

I agree with both parts of the proposal. A fourth reason to remove the first item would be the casual wording of the current text. It reads like it's just an example, but the semantics it describes aren't defined anywhere else, to the best of my knowledge. A fifth reason would be that there is no similar rule for updates with only a departure time, so this rule introduces an inconsistency without a clear rationale.

Regards,

Jorden

[Thomas Koch]

+1

Op dinsdag 8 april 2014 17:03:45 UTC+2 schreef Chiara Micca:

[Chiara Micca]

Hi all,

Thanks for the comments. 

It looks like there is consensus on these proposals, so I will proceed with implementing the two changes.

Thanks!

Chiara

--
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/57303925-1f9e-4d4b-9c94-d6c038cf81f8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Chiara Micca |

Partner Technology Manager |

Geo |

mi...@google.com

[Chiara Micca]

Hi all,

These two changes are now live, see:

https://developers.google.com/transit/gtfs-realtime/reference#ScheduleRelationship_StopTimeUpdate

https://developers.google.com/transit/gtfs-realtime/reference#ScheduleRelationship_TripDescriptor

https://developers.google.com/transit/gtfs-realtime/gtfs-realtime-proto

Cheers,

Chiara