gtfs-validator
gtfs-validator copied to clipboard
MobilityData
Implement service gap verification for feed (GTFS rule)
Is your feature request related to a problem? Please describe. Verify if a feed has too many days without service, or a service gap. This is a GTFS rule implemented in Google Python validator and featured in Google Type Error as TYPE_FEED_SERVICE_DATE_GAP.
Describe the solution you'd like Actual Google GTFS validator behaviour : verifies if feed has effective dates first (if empty or is in a valid date format), then verifies the consecutive dates without service in a feed, leading to an error if it's a big gap.
Describe alternatives you've considered
Additional context Line 59 in Error support priorities https://docs.google.com/spreadsheets/d/1vqe6wq7ctqk1EhYkgtZ0_TbcQ91vccfs2daSjn20BLE/edit#gid=0
@maximearmstrong Same question here - what's considered "too many days" in the Python validator?
If you could include the parameters for these types of validation rules from the Python validator, that would be great.
@barbeau the Python validator pass the service gap interval threshold by parameter, so there's no number of days define in the code to my knowledge.
@timMillet The spec doesn't seem to define a service gap threshold for warnings. What should it be?
@maximearmstrong So if you run the Python validator without passing any parameters, does this rule run? Is there a default value somewhere, or does it just skip the rule?
To my knowledge there aren't any "service gap thresholds" defined in the spec.
@barbeau my bad, I thought it was passed by parameters, but I figured out the service gap threshold is computed when the method is called https://github.com/google/transitfeed/blob/master/transitfeed/schedule.py#L972
This should be flagged as a warning. I think the way the old validator handled service gaps was quite good but if I had to give a specific number of days I would say if there is a gap 15 days or bigger it should be flagged as a warning (considering that most holidays are not more than 14 days long).
The output of the validator should be something like this:
WARNING: There is a [X] day gap in service btween [date 1] and [date 2]. No service is provided for these dates. Please ensure this is normal.
We usually don't add rules that are not clearly specified in the spec or best practices (this is the case here), but we make exceptions for what the community thinks is valuable to check (point_near_origin, fast_travel_between_consecutive_stops, unused_trip, just to name a few). This is done on a case-by-case basis, by discussing with the community. We are in favor of having the spec modified first before adding the check in the validator.
