Too Fast Travels - Can we please get a parameter to turn this off?

[bdferris]

From [email protected] on October 20, 2009 15:01:18

What steps will reproduce the problem? 1. Try validating LA Metro's published Feed. 2. 3. What is the expected output? What do you see instead? Under 1.2.1 we had 19(?) warnings that our route short name was too long -
a condition endemic to the way we're exporting our Lines/Routes system.

Under 1.2.2, in addition, we see 492903 warnings of too fast travels.
Some of it has to do with the fact that we don't export seconds in our
HASTUS export (only minutes), the Validator assumes that, since the
minutes don't change, there was zero time between stops. (A not
unreasonable assumption, certainly, but really counterproductive to us.)

In addition, we're getting warnings of 55 kph travel on our light rail
lines (is it unreasonable that they should go that fast? - what were the
assumptions?) What version of the product are you using? On what operating system? 1.2.2 - Issue new to this version. Please provide any additional information below.

Original issue: http://code.google.com/p/googletransitdatafeed/issues/detail?id=193

[bdferris]

From [email protected] on October 20, 2009 18:18:49

Have you tried asked HASTUS to not round times? A vehicle can't be in two places at
the same time.

I've heard other people complaining about the warning when two stop_time rows have
the same time due to rounding. How about we only show the warning when the stops are
further apart then can be traveled in a minute?

What do you think is a reasonable max speed for this route_type?
"0 - Tram, Streetcar, Light rail. Any light rail or street level system within a
metropolitan area."
I agree, in hindsight, 50km/h is too low. How about 100?

Labels: Language-Python Type-Defect App-FeedValidator Priority-High

[bdferris]

From [email protected] on October 21, 2009 09:04:21

HASTUS does have a setting that turns off rounding, but IIRC, it's a setting for
everything, and most agencies do scheduling in minute increments (except perhaps
subways where timing can be exact, Montreal comes to mind).

We can turn off interpolation of times between timepoints and only export timing
point times in stop_times.txt.  However, then we rely on the GTFS consumer to
interpolate the times at stops, and frankly, I trust HASTUS and my own agency's
local knowledge of the street system much more to interpolate times than perhaps
somebody working on a weekend project.

Also, if we do provide seconds in our GTFS field, how would a consuming application
use those seconds?  I know that Google Transit only displays times at the minute-
level, but there aren't any rules or requirements for every GTFS consumer and
without those, I can't trust a program to interpret the seconds correctly.

[bdferris]

From [email protected] on October 21, 2009 11:34:15

I agree that requiring the consumer to interpolate times does make the data harder to
use.

I'm not worried that GTFS consumers will have a hard time interpreting the seconds
correctly. I see 3 possibilities, from worse to best:
  ignore the seconds, effectively rounding down time to nearest minute. produces max
error of 59 seconds
  round to nearest minute. (Similar to what is done before GTFS creation today?) max
error of 30 seconds
  use full precision

If you change from rounding during GTFS creation to exporting times to the nearest
second you increase the maximum possible error from 30s to 60s for some consumers,
make no difference for others and enable apps that want full precision (such as
animating a schedule) to work better.

[bdferris]

From [email protected] on October 22, 2009 05:43:21

NCTD has a big problem with this error.  Between this version of the validator and
the previous, we've gone from no errors to over 16000.  We also use HASTUS, and as
Devin Braun from SDMTS noted we are using minute increments.  So every single stop
for our trains now seems to be an issue.  Will this mean our new schedule which we
were planning on loading Friday morning to our website will not pass validation now?

[bdferris]

From [email protected] on October 22, 2009 06:06:30

gonctd: "Too Fast Travels" is a warning when the difference in time is 0 seconds. Your
data doesn't have any errors, as far as I can see. If you have questions about the
other warnings please check http://groups.google.com/group/google-transit-partner- support

[bdferris]

From [email protected] on October 22, 2009 23:10:17

It dies (I had assumed) with an error.

"The server couldn't fulfill the request. Error code: 407."

I just thought that the 492,903 Warnings (A record for me, by the way) had caused the
program to die.  Is this a different Issue?

I see now ( issue 195 ) that this might not have anything to do with the large number
of warnings, but its a little confusing. What suddenly changed? I didn't notice
anything in the changelog that looked like it discussed it.

I'm attaching a PDF of the output.

[bdferris]

From [email protected] on October 28, 2009 15:25:22

(No comment was entered for this change.)

Status: Accepted
Owner: tom.brown.code

[bdferris]

From [email protected] on October 28, 2009 16:09:24

http://codereview.appspot.com/143052 suppresses the warning about travel in 0 seconds
when the distance is less than max_speed for one minute and the times are rounded to
the nearest minute. It also increases the max average speed for route_type=0 - Tram,
Streetcar, Light rail to 100km/h.

I ran this against the lacmta data and it reduced the warning count from ~493k to 264
Too Fast Travels. It looks like there are a few trips that jump more than 1 mile in 0
seconds.

[bdferris]

From [email protected] on November 04, 2009 13:20:02

Fixed with https://code.google.com/p/googletransitdatafeed/source/detail?r=1131 to be
in next release.

Status: Fixed