Add "UNSCHEDULED" value for StopTimeUpdate.ScheduleRelationship for frequency exact_times=0 trips about transit HOT 4 CLOSED

What was the value that we removed last time here?

from transit.

@skinkie I think this removal of the REPLACEMENT value for TripDescriptor.ScheduleRelationship is most likely the removal you're thinking of. This proposal isn't related, as it's for StopTimeUpdate.ScheduleRelationship, not TripDescriptor.ScheduleRelationship, and isn't related to replacing anything.

from transit.

If the TripDescriptor.ScheduleRelationship is already UNSCHEDULED (meaning that the trip is running with exact_times=0), can't clients infer that the StopTimeUpdate.ScheduleRelationship is also unscheduled? An ADDED TripDescription.ScheduleRelationship doesn't also have an equivalent value in the StopTimeUpdate.ScheduleRelationship, for example.

from transit.

@paulswartz We could write rules into the GTFS-rt spec language instructing consumers to infer this, but the data itself would still be conflicting (some protobuf consumer bindings automatically populate the data with the default values, so to software it looks like all the StopTimeUpdate.ScheduleRelationships are all populated as SCHEDULED, even if left empty in the feed). For data quality, IMHO it's better to provide an explicit enum to make it all match up.

As regards to ADDED, IMHO ADDED is currently too under-specified as-is and barely useable - we plan to clean this up in Service Changes. So I wouldn't use that as an example to follow here.

from transit.