|Common Work Packages|
|BZE Work Packages|
|PTUA Work Packages|
|SDGs Sustainable Development Goals|
|Published by||Patrick Sunter|
|License||CC BY-SA 4.0|
|Automatic translations||Français, Español, 中文, العربية, Русский, Kiswahili and others|
|Cite as "OSSTIP/WPBZE2". Appropedia. 2021. Retrieved 2021-08-1.|
WPBZE1- Phase 1 Display of new BZE Network in OSSTIP
This is a Work Package as part of the OSSTIP project.
- BZE’s Proposed updated network and frequency information
- Working OSSTIP platform for display of existing PT timetable (OSSTIP/WP4)
- Network->timetable conversion tools (OSSTIP/WP5)
- Installed instance of OSSTIP with relevant GIS data uploaded,
- Created map-based analysis,
- and updated documentation.
Estimated Time: Medium
Requirements Summary[edit | edit source]
- Investigate OpenTripPlanner's Batch Analyst Mode routing capabilities/speed
- Investigate the Open Source Accessibility Toolkit extension to OTP for these types of calculations.
Results/Work[edit | edit source]
(2013-08-08)[edit | edit source]
Am trying to follow instructions of OTP's https://github.com/openplans/OpenTripPlanner/wiki/Batch-Analyst mode to see how good its capabilities are in this area. This seems to require installing and setting up a development environment for the project, based on Eclipse.
The other main option would seem to be using the Open Source Accessibility Toolkit code which seems to include OD routing capability by centroid of traffic zones. It is quite well documented, however this is probably not updated to work with the latest OTP. It does include some nice visualisation capabilities though, if we want to calculate things like modal accessibility difference between PT and car.
OTP's performance for O-D routing via the PT network[edit | edit source]
From the OSAT manual, some indicative routing speed results from 2011 using OTP (capabilities of computer used not stated):
"Trip calculations can range from <100ms to >2 seconds per trip. In the long run for DC, it comes out to be about 240ms per trip, or 4 minutes to calculate 1000 trips. For King County, which has a larger graph, it comes out to be about a second per trip. Runtime also depends on your processor."
(2013-09-18)[edit | edit source]
Can now do a test comparison of OTP's routing results on the existing public transport network, compared to Netview on BZE's new network. I wrote a Python script to calculate this, so it is quite repeatable. The dependency not included in the Python distribution I used is NumPy - here is a nice tutorial on how to use it.
The initial first-cut result is that the Netview routing results are just slightly faster.
There are a lot of caveats though:-
- The OTP results are for the current network, whereas BZE are for their modified network;
- The OTP is based on a GTFS schedule and at a particular time of day, so the wait times will be different for each route, and dependent on the time of day.
- Whereas the Netview results used not a schedule, but a route speed for different modes modified by VISTA survey results. It also contained a 'wait time' parameter at the start.
- I am also aware the bus network used for the OTP calculations is a bit problematic, the GTFS data likely needs more work first.
I would be interested to work on visualising these O-D routing results in qGIS :- that likely involves creating Shapefiles. See OSSTIP/visualise OD matrix in QGIS.
Also, when I play around with the results a bit more, it should help with working out the possible shortfalls in the BZE network, by sorting the comparison CSV file for the routes that are coming out slower in Netview on the new network.