MobilityData / gtfs-validator

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

Implement minimum transfer time verification #159

Open maximearmstrong opened 4 years ago

maximearmstrong commented 4 years ago

Is your feature request related to a problem? Please describe. Minimum transfer time should be present and valid. This is a GTFS rule implemented in Google Python validator and featured in Google Type Error as TYPE_TRANSFER_MIN_TRANSFER_TIME_AND_INVALID_TYPE, TYPE_TRANSFER_MIN_TRANSFER_TIME_IS_MISSING, TYPE_TRANSFER_MIN_TRANSFER_TIME_IS_NEGATIVE and TYPE_TRANSFER_MIN_TRANSFER_TIME_IS_VERY_LARGE.

Describe the solution you'd like Actual Google GTFS validator behaviour : verifies if minimum transfer time is not missing, if it's not negative, nor equal or greater than 24h.

Describe alternatives you've considered

Additional context Line 124, 125, 126 and 127 in Error support priorities https://docs.google.com/spreadsheets/d/1vqe6wq7ctqk1EhYkgtZ0_TbcQ91vccfs2daSjn20BLE/edit#gid=0

barbeau commented 4 years ago

This is another rule that may need to be configurable - the "not greater than 24 hrs" doesn't appear in the spec or best practices:

It's worth noting that the best practices say:

1: This is a timed transfer point between two routes. The departing vehicle is expected to wait for the arriving one, with sufficient time for a passenger to transfer between routes.This transfer type overrides a required interval to reliably make transfers. As an example, Google Maps assumes that passengers need 3 minutes to safely make a transfer. Other applications may assume other defaults.

maximearmstrong commented 4 years ago

@barbeau @timMillet Should every threshold verified by the Python validator be treated as warnings in our validator? Therefore not a GTFS error, but still verifying the Python validator rules.

barbeau commented 4 years ago

@maximearmstrong IMHO it should be considered on a case-by-case basis. The problem with labeling rules as warnings is that some producers tend to ignore everything that's not an error. If there are clear, common cases of bad data IMHO it makes sense to have an error for a threshold. The (0,0) bus stop location is one example. Some (like this min transfer time rule) may be a bit fuzzier and require some discussion in the community of what an error threshold should be. One data-driven approach is to programmatically examine all the feds from OpenMobilityData.org and pick the 95th percentile as the error threshold.

lionel-nj commented 4 years ago

We are considering making numeric thresholds user configurable to notice producers that although the data is syntactically correct (here min_transfer_time >0), the value is too small or too big.

See related comments: https://github.com/MobilityData/gtfs-validator/pull/71#discussion_r423150989