-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that there are at least 7 contiguous days during which all feeds are valid #4
Comments
@pouyalireza Can you close or delete this? |
This task is addressed in the newly added feed duration visualizer. |
This is still a Trillium process issue. How does Trillium trigger a build so that looking back seven days all feeds are valid. We should consider this task complete, when we have a new db in place with 7+ days of contiguous validity, and Trillium understands the issues associated with making this happen. Speed is an issue for ODOT on this issue; we can use a "solid" snapshot of the network to build some report documents. This db build should include the P&R update. |
This may be obvious, but I think that because it needs another db build, this needs to be preceeded by an answer to #16 related to evaluating where the tool will be hosted moving forward. @BenFields724, @pouyalireza, do we have an answer to that question? I think that this may also require, us to not include services that don't run year round, because those significantly shrink our window. @ed-g, in looking at the overlap of service, it looks like feed_end_date could be adjusted to extend this window, while keeping end_date in calendar.txt the same, which I would hope would allow those short term services to continue showing up correctly in google transit, etc. |
Trillium should proceed "with an eye to an ongoing, perhaps quarterly build process by Trillium." (via M Barnes, @ODOT-RPTD-mb). cc: @ed-g Can someone please assign this to @antrim or @ed-g ? I do not have access to make assignments on this repo. |
cc: @thomastrillium Here is what the Spec says about feed_info.feed_start_date and feed_info.feed_end_date:
(https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#feed_infotxt) GTFS Best Practices says:
(http://gtfs.org/best-practices/#publishing_4) Proposed next steps:
|
|
|
@ODOT-RPTD-mb @PPaulsonOregonDOT @srinivas13794 @BenFields724 are the GTFS feeds in the Tna tool loaded from the Public+Private gtfs archive site? If not, what is the process for fetching GTFS feeds? |
Yes, feeds are captured from private+public Trillium site. |
Uploading feeds from http://archive.oregon-gtfs.com/archive-download-private/Oregon-Private-GTFS-feeds-2017-09-18Z.zip (you'll need a login to access that URL). Notes to self: Next steps after GTFS upload are "Run Update Queries" in the admin interface, and then "Activate Database".
It's necessary to make a database "inactive" before uploading GTFS. That part of the admin interface is currently broken due to #64 but you can update |
If we create a GIST index on census_blocks.shape, testing for contained points goes much faster. Similar story for gtfs_trips.shape and census_tracts. In general it's a good idea to index any geometry columns when using PostGIS. create index gtfs_trips_shape_idx ON gtfs_trips using gist(shape);
create index parknride_geom_idx ON parknride using gist(geom);
create index census_blocks_shape_idx on census_blocks using gist (shape) ;
create index census_tracts_shape_idx on census_tracts using gist (shape) ;
create index census_places_shape_idx on census_places using gist (shape) ;
create index census_congdists_shape_idx on census_congdists using gist (shape) ;
create index census_states_shape_idx on census_states using gist (shape) ;
create index census_urbans_shape_idx on census_urbans using gist (shape) ;
|
This will enable parallel queries on the database which could speed things up depending on the exact query. alter database september17 set max_parallel_workers_per_gather= 8; |
Pretty close, there are a couple agencies which are ruining the party. Klamath seems to have expired a couple years ago, and CCCXPRESS starts in the future. september17=# select enddate::date, feedname from gtfs_feed_info order by enddate asc limit 10;
enddate | feedname
------------+-----------------------------
2016-09-05 | klamathshuttle-or-us
2017-10-31 | washingtonparkshuttle-or-us
2017-12-02 | trimet-portland-or-us
2017-12-06 | cccxpress-or-us
2017-12-25 | valleyretriever-or-us
2017-12-30 | salem-or-us
2018-01-01 | cascadespoint-or-us
2018-01-01 | albanytransit-or-us
2018-01-01 | cooscounty-or-us
2018-01-01 | amtrakcascades-or-us
(10 rows)
september17=# select startdate::date, feedname from gtfs_feed_info order by startdate desc limit 10;
startdate | feedname
------------+-----------------------------
2017-09-25 | cccxpress-or-us
2017-09-10 | ctran-wa-us
2017-09-03 | salem-or-us
2017-09-03 | trimet-portland-or-us
2017-08-01 | northwestpoint-or-us
2017-08-01 | pacifictransit-wa-us
2017-06-18 | lanetransitdistrict-or-us
2017-05-11 | highdesertpoint-or-us
2017-04-01 | washingtonparkshuttle-or-us
2017-02-01 | hut-or-us
(10 rows) |
CCCXpress from 14 September looks like it starts on the 13th. I wonder why tna tool thinks it starts on the 25th. oregon-gtfs.com also shows it as starting on the 13th.
UPDATE: it's probably because cccxpress is a college commuter bus and doesn't start until term does. september17=# select * from gtfs_calendars where serviceid_agencyid = '256';
serviceid_agencyid | serviceid_id | gid | monday | tuesday | wednesday | thursday | friday | saturday | sunday | startdate | enddate
--------------------+--------------------+-----+--------+---------+-----------+----------+--------+----------+--------+-----------+----------
256 | c_842_b_2858_d_31 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 20170925 | 20171206
256 | c_842_b_2858_d_15 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 20170925 | 20171206
256 | c_2279_b_2859_d_15 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 20170925 | 20171206
(3 rows)
|
Klamath Shuttle (aka Crater Lake Trolley) should run this year until October 10th or 11th. but we're checking with them to make sure. UPDATE: Crater Lake Trolley is a loop route where you can't disembark the trolley around the lake. It is not included in google transit for that reason. The Klamath Shuttle from the Amtrak station to the lake is active only during summer months, next from 7/1/2018 - 8/3/2018. UPDATE 2: The schedule information was outdated from 2016, and I've loaded the current version of the feed with updated schedule for 2018. |
Protip: use curl -H 'accept: application/json' http://tna.trilliumtransit.com:8080/TNAtoolAPI-Webapp/queries/transit/Daterange?dbindex=10 |
@ODOT-RPTD-mb @PPaulsonOregonDOT it looks like there is a little over a month of contiguous validity (September 25th through October 31st), with the single exception of the Klamath shuttle which runs only seasonally and is done for the year. http://tna.trilliumtransit.com/TNAtoolAPI-Webapp/Daterange.html?&dbindex=10 Let me know if this gives you what you need for the report? september17=# select enddate::date, feedname from gtfs_feed_info order by enddate asc limit 5; select startdate::date, feedname from gtfs_feed_info order by startdate desc limit 5;
enddate | feedname
------------+-----------------------------
2017-10-31 | washingtonparkshuttle-or-us
2017-12-02 | trimet-portland-or-us
2017-12-06 | cccxpress-or-us
2017-12-25 | valleyretriever-or-us
2017-12-30 | salem-or-us
(5 rows)
startdate | feedname
------------+-----------------------
2018-07-01 | klamathshuttle-or-us
2017-09-25 | cccxpress-or-us
2017-09-10 | ctran-wa-us
2017-09-03 | trimet-portland-or-us
2017-09-03 | salem-or-us
(5 rows) |
Potentially this works for a short term fix. I would expect Columbia Gorge Express to show up (or not show up) in the same way that the Klamath Shuttle does in that it is also a seasonal summer service that is not currently operating? For the longer term we probably want to:
|
Sorry just a quick response for now
|
@ed-g Generally, we know which feeds are seasonal (at this point, I think it's just Klamath Shuttle and Columbia Gorge Express). |
One observation that I just made related to this is that the floating box with all of the Oregon Transportation Agencies (OTA) currently shows now agencies with expired feeds, which would suggest that at least today should be considered a valid day, and I believe this entire week should qualify. However, in looking at the data graph, there are no days when all feeds are valid. This might be related to issue #32, but it's unclear where in the process the date information is getting corrupted/broken. |
@antrim I'll let you make a time estimate here |
@PPaulsonOregonDOT Phil comment ported from closed issue: |
@antrim @PPaulsonOregonDOT @ed-g - word file with some additional notes on GTFS feed set updates and archiving. |
For each new GTFS dataset ensure that there are at least 7 contiguous days during which all feeds are valid (are between feed start and end dates) (feed can both be valid and have no service for period in question) [Trillium is the logical lead on this activity]
Possible tactics include:
This is particularly useful for GTFS-ride. i.e. It is particularly useful to know if past service dates were valid.
The text was updated successfully, but these errors were encountered: