Validation metrics #52

sdrewc · 2017-09-15T21:17:00Z

Adds a new file, route_stats_ft.txt to contain route-level statistics for specified time windows, and adds additional fields to stop_times_ft.txt and trips_ft.txt to support calculation of statistics

In the table of optional files, the link labeled "fare_rules_ft.txt" is 404. File has been renamed in the standard to fare_periods_ft, so change it here as well.

Update fares.md; misc cleanup throughout

Start to add TCQSM variables

TCQSM edits #1

and remove number_loading_areas, which belongs at a station/stop in stops_ft

TCQSM Edits #1.2

Conflicts: README.md files/vehicles_ft.md Signed-off-by: Drew <[email protected]>

…time range and set of days. Signed-off-by: Drew <[email protected]>

Signed-off-by: Drew <[email protected]>

…te_stats_ft.txt Signed-off-by: Drew <[email protected]>

e-lo · 2017-09-20T17:36:03Z

files/routes_stats_ft.md

+
+Optional Attributes	| Description										
+----------			| -------------		
+`schedule_time`		| Integer, mean number of minutes from scheduled `arrival_time` at first stop to scheduled `departure_time` at last stop.


suggest avg_scheduled_runtime ?

e-lo · 2017-09-20T17:36:35Z

files/routes_stats_ft.md

+Optional Attributes	| Description										
+----------			| -------------		
+`schedule_time`		| Integer, mean number of minutes from scheduled `arrival_time` at first stop to scheduled `departure_time` at last stop.
+`actual_time`		| Integer, mean number of minutes from actual `arrival_time` at first stop to actual `departure_time` at last stop.


suggest avg_observed_runtime

e-lo · 2017-09-20T17:37:59Z

files/routes_stats_ft.md

+----------			| -------------		
+`schedule_time`		| Integer, mean number of minutes from scheduled `arrival_time` at first stop to scheduled `departure_time` at last stop.
+`actual_time`		| Integer, mean number of minutes from actual `arrival_time` at first stop to actual `departure_time` at last stop.
+`std_dev`			| Float, standard deviation of `actual_time`.


suggest: stdev_observed_runtime

should we have for schedule too? there is certainly variation

e-lo · 2017-09-20T17:38:24Z

files/routes_stats_ft.md

+`schedule_time`		| Integer, mean number of minutes from scheduled `arrival_time` at first stop to scheduled `departure_time` at last stop.
+`actual_time`		| Integer, mean number of minutes from actual `arrival_time` at first stop to actual `departure_time` at last stop.
+`std_dev`			| Float, standard deviation of `actual_time`.
+`semi_std_dev`		| Float, semi-standard deviation between scheduled and actual route run time.


semi_stdev_observed_runtime

e-lo · 2017-09-20T17:39:11Z

files/routes_stats_ft.md

+`actual_time`		| Integer, mean number of minutes from actual `arrival_time` at first stop to actual `departure_time` at last stop.
+`std_dev`			| Float, standard deviation of `actual_time`.
+`semi_std_dev`		| Float, semi-standard deviation between scheduled and actual route run time.
+`schedule_stop_time`| Integer, mean number of minutes scheduled stop time.


meaning time spent the stop? or time serving passengers specifically? time with doors open? just be specific.

Might also want to use stopped rather than stop

e-lo · 2017-09-20T17:39:44Z

files/routes_stats_ft.md

+`semi_std_dev`		| Float, semi-standard deviation between scheduled and actual route run time.
+`schedule_stop_time`| Integer, mean number of minutes scheduled stop time.
+`actual_stop_time`	| Integer, mean number of minutes actual stop time.
+`stop_delay`		| Integer, mean number of minutes of stop delay.


not sure what delay this is referring to and how we would get it from data?

is this the deviation from the GTFS schedules and the actual dwell time? the gtfs stuff might be hard to trust...hmmm

I meant stop_delay for stop delay to just be the diff between scheduled and observed stopped time. I agree we may not be able to get this from GTFS; often arrival_time==departure_time, but that's why it's optional

e-lo · 2017-09-20T17:42:00Z

files/stop_times_ft.md

@@ -17,6 +17,8 @@ File MAY contain the following attributes:

 Optional Attributes		| Description										
 ----------				| -------------		
+`actual_arrival_time`	| Actual arrival time at a specific stop for a specific trip on a route in HH:MM:SS format measured from midnight.  For trips that span multiple dates, the time should be entered as a value greater than 2400000


wonder if this needs to be a separate file with similar values for matching with dates/times as you have in routes_stats?

e-lo · 2017-09-20T17:43:04Z

files/trips_ft.md

@@ -13,3 +13,15 @@ Required Attributes	| Description
 `trip_id`			| ID that uniquely identifies a vehicle trip
 `vehicle_name`		| Name of vehicle type, which is to match a description in [`vehicles_ft.txt`](vehicles_ft.md)

+File MAY contain the following attributes:


is this for individual trips wheras route_stats is for groups of trips? suggest a new file

e-lo

I made specific line comments, but I'm wondering if you need separate files for performance rather than lumping with the scheduled data?
See line-level notes about naming conventions. I am not wedded to these specific names, but think they should be a little more explicit.
What about what you originally termed "virtual routes" or corridor segments? I think it would be good to define and have a file to summarize them.

e-lo · 2017-09-20T19:20:17Z

Decided to move information in this pull request to a new, to-be-named standard: https://github.com/osplanning-data-standards/GTFS-RPT

barbeau · 2017-09-21T17:05:30Z

Just curious - have you all been following GTFS-ride?

https://groups.google.com/forum/#!topic/transit-developers/cPTGF-rxtMo

Do you see GTFS-RPT you mention above overlapping with GTFS-ride at all, or will it stick primarily to vehicle performance (and not ridership)?

e-lo · 2017-09-21T17:47:01Z

Howdy! We have been following, contributing comments to, and excited about using GTFS-ride. We will be using it as the standard ridership output from our Fast-Trips transit assignment software. However, there are several other aspects of transit travel that we need to move data around for, so we had to extend GTFS into the following:

GTFS-PLUS ...we are open to a better name... which brings in more aspects about the actual transit service like vehicles and capacities.
dyno-path, which shows individual passenger trajectories.
dyno-demand, which lists individual passenger demand.

...and then after talking amongst our team we decided to create GTFS-RPT (or whatever we decide to call it @sdrewc gets naming rights) in order to capture the other aspects of performance (travel times, reliability), summarized across a few dimensions similar to how GTFS-RIDE does for ridership.

If there is another standard or effort that is underway to summarize performance as such, we would be very open to adopting it as well as morphing this one to be something that is more universally helpful to the community. We are all-ears!

barbeau · 2017-09-22T13:41:49Z

@e-lo Awesome, thanks for the summary! I'll keep tabs on these. The one we'd most likely be immediately interested in is the GTFS-RPT, which, from my understanding, would be capturing things like schedule deviation and on time performance at stops, etc. We've been archiving GTFS-realtime data from a few places, originally for this project - https://www.nctr.usf.edu/wp-content/uploads/2017/05/NCTR-79050-17-Transit-Service-Reliability.pdf. As part of this we developed this proof-of-concept on time performance calculation tool - https://github.com/CUTR-at-USF/ontime-performance-calculator. My main interest is producing performance metrics that can be used for better real-time predictions using machine learning, but it could serve a lot of other purposes as well. There is definitely a need for a format to exchange this type of data, and we haven't really dove into that yet.

ddorinson and others added 30 commits March 21, 2017 19:08

Reflect change in fare...ft file name & path

c655124

In the table of optional files, the link labeled "fare_rules_ft.txt" is 404. File has been renamed in the standard to fare_periods_ft, so change it here as well.

Fix table formatting

2b42f81

Replace fare_class, fare_rules_ft, misc cleanup

af7f971

Add link to fare_rules.md file

3ea6fde

More cleanup to match v.0.3.0

b9a643f

Cleanup table formatting and code fragments

6505736

Final set of changes to match v.0.3.0 spec

a167e0d

Fixed wiki URL

13358c4

Add file link; fix typos

20883f5

Fix table formatting

1414662

Fix table formatting, layout

f4751ea

Fix table formatting, layout

e91737b

One more layout fix

54ebc3d

Fix table formatting, layout

736232a

Merge pull request osplanning-data-standards#39 from ddorinson/patch-1

10349ad

Update fares.md; misc cleanup throughout

Update vehicles_ft.md

122c0e7

Start to add TCQSM variables

Create vehicles_ft.md

5ca49bc

Merge pull request #1 from sdrewc/sdrewc-patch-1

54e779c

TCQSM edits #1

accel, decel, max_speed

b934130

minor formatting changes

e55703c

Create vehicles_ft.md

2b8675d

Create vehicles_ft.md

1b32a0d

Add percent_using_farebox and formatting fixes

cf438ca

Add percent_using_farebox

0572d65

add max_speed, accel and decel back in.

f094137

and remove number_loading_areas, which belongs at a station/stop in stops_ft

Add number_loading_areas

2f8f2ea

Add TCQSM parameter text

fd8f743

Add TCQSM parameter text

7388d47

Add TCQSM parameter text and dwell_formula

eb8c75e

Add TCQSM parameter text

c99732c

sdrewc and others added 8 commits June 14, 2017 13:24

Merge branch 'master' into sdrewc-patch-1

7bf329e

Merge pull request #2 from sdrewc/sdrewc-patch-1

1836221

TCQSM Edits #1.2

Merge branch 'queued' into master

6efc5ae

Merge remote-tracking branch 'upstream/master'

2525738

Conflicts: README.md files/vehicles_ft.md Signed-off-by: Drew <[email protected]>

Add route_stats_ft.txt to hold route-level statistics for a date and …

96cff46

…time range and set of days. Signed-off-by: Drew <[email protected]>

Add more statistics

86908e2

Signed-off-by: Drew <[email protected]>

Add fields to upstream files to support calculating statistics in rou…

f346ee6

…te_stats_ft.txt Signed-off-by: Drew <[email protected]>

Fix formatting

e3f976b

e-lo reviewed Sep 20, 2017

View reviewed changes

e-lo requested changes Sep 20, 2017

View reviewed changes

e-lo closed this Sep 20, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Validation metrics #52

Validation metrics #52

sdrewc commented Sep 15, 2017

e-lo Sep 20, 2017 •

edited

Loading

e-lo Sep 20, 2017 •

edited

Loading

e-lo Sep 20, 2017 •

edited

Loading

e-lo Sep 20, 2017

e-lo Sep 20, 2017

e-lo Sep 20, 2017

e-lo Sep 20, 2017

sdrewc Sep 21, 2017

e-lo Sep 20, 2017

e-lo Sep 20, 2017

e-lo left a comment

e-lo commented Sep 20, 2017

barbeau commented Sep 21, 2017

e-lo commented Sep 21, 2017

barbeau commented Sep 22, 2017

Validation metrics #52

Validation metrics #52

Conversation

sdrewc commented Sep 15, 2017

e-lo Sep 20, 2017 • edited Loading

Choose a reason for hiding this comment

e-lo Sep 20, 2017 • edited Loading

Choose a reason for hiding this comment

e-lo Sep 20, 2017 • edited Loading

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

sdrewc Sep 21, 2017

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

e-lo Sep 20, 2017

Choose a reason for hiding this comment

e-lo left a comment

Choose a reason for hiding this comment

e-lo commented Sep 20, 2017

barbeau commented Sep 21, 2017

e-lo commented Sep 21, 2017

barbeau commented Sep 22, 2017

e-lo Sep 20, 2017 •

edited

Loading

e-lo Sep 20, 2017 •

edited

Loading

e-lo Sep 20, 2017 •

edited

Loading