Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Ignore 0 travel time for very close stops #110

Closed

Conversation

Tristramg
Copy link

We have lots of validations errors because timetables are rounded to the minute.

This would allow to reduce the noise in the validation results

@codecov-io
Copy link

Codecov Report

Merging #110 into dev will not change coverage.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff            @@
##                dev     #110   +/-   ##
=========================================
  Coverage     32.64%   32.64%           
  Complexity      405      405           
=========================================
  Files           141      141           
  Lines          6396     6396           
  Branches        714      714           
=========================================
  Hits           2088     2088           
  Misses         4090     4090           
  Partials        218      218
Impacted Files Coverage Δ Complexity Δ
...om/conveyal/gtfs/validator/SpeedTripValidator.java 44.68% <0%> (ø) 5 <0> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f133550...42d13e7. Read the comment docs.

@landonreed
Copy link
Contributor

@Tristramg, I agree this can become very noisy. I like the solution you have proposed. @abyrd?

@abyrd
Copy link
Member

abyrd commented Apr 16, 2018

@Tristramg I agree this can be a problem. These validations produce a ton of noise on many feeds, for exactly the reason you mentioned: it's common to round off timetables. I consider that to be a warning-worthy characteristic of GTFS feeds, but one that is nonetheless common and tolerable.

I would suggest instead that we attempt to detect rounded off feeds (i.e. all seconds are 00) and on those feeds we register a single feed-wide warning about rounding, and only on feeds with that characteristic we would disable zero-time hops.

Alternatively on a per-hop basis, we can disable the warning if the starting and ending stop_times end in 00 seconds and imply a realistic upper bound on speed (as you checked with the 300m limit).

@landonreed
Copy link
Contributor

Closing in favor of #145.

@landonreed landonreed closed this Oct 11, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants