|Common Work Packages|
|BZE Work Packages|
|PTUA Work Packages|
|SDGs Sustainable Development Goals||SDG11 Sustainable cities and communities|
|License||CC BY-SA 4.0|
|Translate to||Français, Español, Kiswahili, 中文, العربية, Русский, more|
|Export to||PDF, LaTeX, EPUB, ODT|
|Cite as Patrick Sunter (2021). "OSSTIP/WP6". Appropedia. Retrieved 2021-10-19.|
WP6- Capacity to modify and extend existing route lines from GTFS into new timetable
This is a Work Package as part of the OSSTIP project.
- Relevant GTFS files for region of interest to do testing upon (e.g. Melbourne) See (OSSTIP/WP1).
- A design of output format for network topology information, to know what to convert the GTFS line information into for further use and modification (necessary to create new timetable). Developed in OSSTIP/WP5.
- New scripts committed into OSSTIP repository to allow extracting relevant information from a GTFS file.
- Documentation on how to use these, sample results.
Estimated Time: Medium
Status: WP created in Sep 2014 during PTUA Action-case. As of 2014-11-05 :- timetable and frequency modification capability working, now working on line-extension capability.
Requirements Summary[edit | edit source]
Motivated by PTUA project wanting to extend several train lines, and increase frequency along several existing bus and tram lines.
As compared to SimpleGTFSCreator previous capability to create new bus lines based on a GIS network representation OSSTIP/WP5 and several scripts :-
In this case, since modifying existing lines, we need to add several new steps to the workflow. The workflow effectively will become:-
Stage 1) add ability to read info for selected lines out of a GTFS file and:-
- Save info re average headway (minutes between vehicle visits at stop) at different periods of the day.
- Similarly, calculate and save info on average speeds on route sections during different periods of the day.
We then need to give users tools to modify these speeds and frequencies in a convenient way.
- I.E. Based on an input GTFS, copy some lines across directly, versus others should be re-written (based on new specification), and some scrapped.
- (Or a minimal 'quick' version of this is just to create entirely new GTFS for new lines, and a 'subset' of old GTFS with some of old lines.
Finally, we need to updgrade the Also need to modify the SimpleGTFSCreator on 'output' end to create a new GTFS timetable, based on this more advanced speed and frequency specification per-route.
Use-Cases[edit | edit source]
So this means, the inital process for creating a modified timetable is:
- Extract from the existing GTFS files a 'Nominal basic full-stop timetable' network topology.
- Extract also the per-route speed and frequency information, in an appropriate format.
Then, in terms of adding the line extension geometries, something like:
- Create the extension geometry, and optionally stops, as per normally needed to create a topology (See OSSTIP/WP5).
- Some sort of specification as to how the line extensions connect up with existing geometry (E.g. via a CSV file, which for each extension route ID, also specifies the original route ID, and the connecting stop)
- Then some way of creating a unified topology of orig. network plus extensions. Perhaps by running another script specifying these?
- Then need a process for specifying modified speed/frequency on the line extensions. Perhaps as part of the previous step, auto-fill the segment speeds of the connecting segment forward?
And last stage:
- Use my "SimpleGTFSCreator" script to create a new timetable based on these chosen modified lines.
- (May need a final script to then "Paste" this in together with a GTFS of several other regular non-extended lines from a previous timetable. Or then again, may be good to keep the modified lines separate from the original lines).
Results[edit | edit source]
2014-11-05: Decoding of GTFS schedule into n/w topology, and line more detailed speed and frequency model implemented[edit | edit source]
Possible Extensions and Further Notes[edit | edit source]
- Re creating a modified train network:- is there a need to try and also do some post-processing to 'smooth' arrival frequencies on multi-route sections sharing same track sections? This is probably a 'nice to have' post-optimisation.