WPBZE4- Conversion of refined BZE Version 2 network into timetable form and display in OSSTIP
This is a Work Package as part of the OSSTIP project.
Inputs:
- 2nd version of BZE’s Proposed updated bus network and speed+frequency information
- Working OSSTIP platform for display of existing PT timetable (OSSTIP/WP4)
- Network->timetable conversion tools (OSSTIP/WP5)
Outputs:
- Updated versions of scripts produced in OSSTIP/WP5 that can now handle time-dependent timetable creation, based on different peak and off-peak speeds specified in network topology shapefiles.
- GTFS timetable for this version 2 network
- Installed instance of OpenTripPlanner with relevant GIS data uploaded and this new GTFS timetable loaded
- Created map-based analysis of accessibility (via Travel time maps) at up to 7 key chosen locations.
Estimated Time: Medium
Status: Complete.
Requirements Summary[edit | edit source]
Key Requirements[edit | edit source]
- Essentially, to repeat the process used in OSSTIP/WPBZE1, with already existing scripts and tools
- This currently requires input from other BZE team members for certain database opertations, to transform GIS network files into the 'abstract PT network topology' intermediate shapefile form, used to actually create the GTFS timetable.
Extension Goals[edit | edit source]
- Support the possibility of time-dependent Peak and Off-Peak networks with differing speeds - based on the pre-existing work of another BZE team member using Matlab scripts and Netview files. This will require modification of the SimpleGTFSCreator script to make creation of schedules time-dependent based on attributes in the abstract network topology shapefile.
- BZE would also like to add a 'bus motorway' network to the regular bus network to account for higher-speed, but lower stop-frequency, buses on highways. Creating this network is being done by another BZE team member, but will require running the conversion process on these scripts also. We can then store these as a separate GTFS timetable, as OpenTripPlanner can easily then load this as well as the regular bus timetable for routing purposes.
- Once these capabilities added, it would be good to also re-run the conversion of the existing BZE version 1 network, and then calculate the routing performance of both networks in the Origin-Destination matrix of key points of interest - then compare performance to the Revision 2 bus network.
Results / Progress[edit | edit source]
11/4/2014: Time-dependent conversion process going[edit | edit source]
Time-dependent schedules for peak and off-peak, and varying this spatially[edit | edit source]
We've now added time-dependent timetable generation capability, at least for a simple model of either being in 'peak' or 'off-peak' network congestion mode. So this is an improvement on OSSTIP/WP5.
This has added a degree of complexity to the SimpleGTFSCreator repository's 'create_gtfs_from_basicinfo.py' script, but performance is still acceptable: less than 10 minutes to create the GTFS timetable for BZE's Melbourne network (of 78 routes).
To the right is a screenshot from QGIS showing how peak-speed reduces across the network based on distance from Melbourne's CBD. This can be applied to an existing network topology file using the script 'assign_speeds_to_network_topology.py' in the SimpleGTFSCreator repository.
Tuning of the schedule to smooth out transitions between peak and off-peak periods[edit | edit source]
Adding different speeds for buses in peak vs off-peak does introduce a timetable design challenge:- the phenomenon of buses in the system 'spreading' as speeds slow down in the off-peak to peak transition, and 'bunching' in the reverse transition as buses on the network already speed up. See figures below to see the effect of this, the first shows a time-space graph with a constant speed of 30km/h, the second shows the same frequency of services specification but with a reduction to 15km/h vehicle speed in peak hours.
To mitigate this I created a modified version of the service frequency specification, as shown in the Python snippet below, that aimed to mitigate this via 'ramping' service frequencies before and after the peak->off-peak transitions. This produced the following time-space graph on our sample route.
While this still isn't perfect (there's still some significant bunching occuring for example), at this stage I think it is of sufficient complexity for our strategic network planning purpose. We could improve the representation by using an even more time-dependent approach so that there is not an instant sharp change between peak and off-peak speeds on the roads. But this would require more data collection, and also potentially slow down the timetable generation code and/or add to the complexity of scripts a lot.
As a result I suggest further modelling of detailed timetable planning is left as a 'future upgrade'. This could be considered alongside other relevant improvements such as modelling the possibility of bus priority measures, and applying constraints to keep transfer times minimal with trains & trams at key sections of the network. It is possible other software exists for this kind of detailed timetable design purpose already, and this should be evaluated i think before further increasing OSSTIP complexity at this stage.
Links with future network re-planning[edit | edit source]
So given the above timetable features are 'ready to go', to do updated timetables for BZE's version 1 and version 2 networks, we're now waiting on:
- The design of a "motorway bus network" that will be a set of routes along existing freeways in Melbourne.
- Possibly, a function for space-dependent speed of buses during off-peak periods.
Once these are both done we can apply the process of converting network routes, to network topology shapefiles, and thence to a GTFS timetable.
30/8/2014: Completed versions of both BZE networks, converted to timetables[edit | edit source]
As of the end of August 2014, we completed converting both BZE V1 and V2 networks into both network topologies, and GTFS timetables (based on a nominated 5-minute bus headway). We ended up adding some routes to the V1 network as a result of evaluation of routing performance, so we have renamed the latest version of the V1 network "V1.2" to denote these added/changed routes.
The topologies are stored in Dropbox at:
- V1.2:
- OSSTIP_BZE/Melbourne_GIS_NetworkDataWork/BZE_New_Network/bus-topology-v1_2-20140724/
- OSSTIP_BZE/Melbourne_GIS_NetworkDataWork/BZE_New_Network/bus-motorway-topology-201404-added-stops/
- V2.0:
- OSSTIP_BZE/Melbourne_GIS_NetworkDataWork/BZE_New_Network_rev2/bus-StreetNetwork-topology-v2-20140722/
- OSSTIP_BZE/Melbourne_GIS_NetworkDataWork/BZE_New_Network_rev2/bus-Motorways-topology-v2-20140722/
All of these directories contain "mkGTFS.sh" shell scripts to run the necessary OSSTIP Python scripts to re-create the topologies and GTFS files from the initial input files.
And the GTFS files are at:
- OSSTIP_BZE/Melbourne_GIS_NetworkDataWork/GTFS_Outputs/BZE-MotorwayBusNetwork-Rev1/
Possible Extensions, Further Notes[edit | edit source]
Evaluating Network Performance at different frequencies[edit | edit source]
- As prepartion for the TransportCamp unconference on Nov 1 2014, we also created timetable versions of the BZE V1.2 network at differing bus network frequencies (headways of 5, 7.5, 10, 12.5, and 15 minutes in peak), and re-ran routing results.
- Results of this analysis are stored in Dropbox at:- fOSSTIP_BZE_FullResults/Routing_Results_Analysis/BZE-Network-V1_2-Results-Differing_Frequencies/
