MobilityData / gtfs-validator

Canonical GTFS Validator project for schedule (static) files.
https://gtfs-validator.mobilitydata.org/
Apache License 2.0
276 stars 100 forks source link

Implement service gap verification for feed (GTFS rule) #142

Open maximearmstrong opened 4 years ago

maximearmstrong commented 4 years ago

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

barbeau commented 4 years ago

@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.

maximearmstrong commented 4 years ago

@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?

barbeau commented 4 years ago

@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.

maximearmstrong commented 4 years ago

@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

brodyFlannigan commented 4 years ago

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.

isabelle-dr commented 1 year ago

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.