search

andreiDamoc / googletransitdatafeed

Automatically exported from code.google.com/p/googletransitdatafeed
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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 reported on code.google.com by rollin.h...@gmail.com on 20 Oct 2009 at 10:01

GoogleCodeExporter commented 8 years ago 
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?

Original comment by tom.brow...@gmail.com on 21 Oct 2009 at 1:18

GoogleCodeExporter commented 8 years ago 
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.

Original comment by db.sd...@gmail.com on 21 Oct 2009 at 4:04

GoogleCodeExporter commented 8 years ago 
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.

Original comment by tom.brow...@gmail.com on 21 Oct 2009 at 6:34

GoogleCodeExporter commented 8 years ago 
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?

Original comment by NCTDGoog...@nctd.org on 22 Oct 2009 at 12:43

GoogleCodeExporter commented 8 years ago 
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

Original comment by tom.brow...@gmail.com on 22 Oct 2009 at 1:06

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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.

Original comment by rollin.h...@gmail.com on 23 Oct 2009 at 6:10

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by tom.brow...@gmail.com on 28 Oct 2009 at 10:25

GoogleCodeExporter commented 8 years ago 
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.

Original comment by tom.brow...@gmail.com on 28 Oct 2009 at 11:09

GoogleCodeExporter commented 8 years ago 
Fixed with http://code.google.com/p/googletransitdatafeed/source/detail?r=1131 
to be 
in next release.

Original comment by tom.brow...@gmail.com on 4 Nov 2009 at 9:20