(→‎Results: -update on Github repositories.)
(better documenting process involved)
Line 14: Line 14:
'''Estimated Time''': Medium
'''Estimated Time''': Medium


'''Status''':
'''Status''': Significant progress (2014-02-07)


== Requirements Summary ==
== Requirements Summary ==
Line 37: Line 37:
* https://github.com/hsenot/nemtools/ (Handles geometric aspects via PostGIS database queries, and NEM files output)
* https://github.com/hsenot/nemtools/ (Handles geometric aspects via PostGIS database queries, and NEM files output)
* https://github.com/PatSunter/SimpleGTFSCreator - Creates a GTFS schedule from a set of intermediate route segment files, stops, and specification of timetable frequency.
* https://github.com/PatSunter/SimpleGTFSCreator - Creates a GTFS schedule from a set of intermediate route segment files, stops, and specification of timetable frequency.
=== 7/2/2014 - working process to create GTFS timetable using scripts, spatial databases and QGIS commands ===
We now have a working process to convert a set of shapefiles, and auxiliary descriptive information, into a GTFS timetable.
It is still 'rough' in sections and could be further improved though.
It involved creating an 'intermediate format' describing route segments, stops, and frequencies along each stop.
The process is roughly as follows.
Initial inputs:-
* A Shapefile layer (vector) describing the routes for the network, that you wish to transform into a GTFS timetable.
* A Shapefile layer (vector) containing the stops along each of these routes.
** (NB - we later created a script to auto-add stops at a given distance along the route. Need to document here).
* Currently, we also need some auxiliary info as variables in a Python script:
** Speeds of each transport mode (later, we want to update ability to be able to create this per-route, and even per-segment)
** A specification of service frequencies throughout the day
TODO: document steps to transform this initial data into GTFS timetable.
Possible improvements:-
* Variable speed per route (?). How exactly are we doing this currently. And could we create a script to modify the shapefiles so the speed on each segment is proportional to distance from the city, as L did for the Netview work?
* Could we further automate and standardise the spatial database creation steps. And re-factor the scripts so they don't require superuser access (via sudo) to the machine you're running them on.
* It would be good to possibly further refactor the nemtools and SimpleGTFSCreator scripts to better organise. Possibly to put them under a common special 'user' on GitHub.
==== Samples of headway definition ====
This is a headway definition over a day, so that there is 5 minutes frequency in peak hour, reducing to 10 minutes inter-peak, and 20 minutes late night and early morning.
default_service_headways = [
    (time(05,00), time(07,30), 20),
    (time(07,30), time(10,00), 5),
    (time(10,00), time(16,00), 10),
    (time(16,00), time(18,30), 5),
    (time(18,30), time(23,00), 10),
    (time(23,00), time(02,00), 20)
    ]

Revision as of 04:37, 7 February 2014

WP Essentials

This is a Work Package as part of the OSSTIP project.

Inputs:

  • Initial GIS data (OSSTIP/WP1),
  • GIS data infrastructure (OSSTIP/WP3),
  • and an updated GIS network of changed PT service lines and frequencies (could be synthetic, or real data from BZEs project work so far etc).

Outputs:

  • software scripts or packages supporting conversion of data formats,
  • documentation on how to use them.

Estimated Time: Medium

Status: Significant progress (2014-02-07)

Requirements Summary

There are two key challenges with utilising software tools that visualise a public transport timetable:

  1. The decision-making involved in generating the actual timetable itself;
  2. The capacity to save the timetable in GTFS format.

The goal in this work package is produce software scripts and/or tools to support this process to be as efficient as possible. This may involve either writing new scripts, or leveraging existing open source applications, such as TransitDataFeeder.

The envisaged starting point is a set of transport routes saved in a common GIS format, such as ESRI Shapefiles, as developed in OSSTIP/WP1. These would be accompanied by a “desired frequency” and “average speed” of each route – probably to be recorded as part of the GIS database.

From this expected starting point, the scripts tools in this WP are envisaged to (a) create a set of “first cut” GTFS timetable files based on the above inputs; and (b) provide some kind of support/process for identifying where the generated timetable most needs to be further edited manually. This process should also be documented, so it can be reproduced as efficiently as possible throughout later stages of the project.

Results

20/11/2013 - intermediate work on relevant scripts

This is in progress, but we have designed a workflow from Geometric routes and stops, through to NEM Files (Needed by BZE for routing using Netview) and also GTFS.

Currently work organised via 2 repos on Git:-

7/2/2014 - working process to create GTFS timetable using scripts, spatial databases and QGIS commands

We now have a working process to convert a set of shapefiles, and auxiliary descriptive information, into a GTFS timetable. It is still 'rough' in sections and could be further improved though.

It involved creating an 'intermediate format' describing route segments, stops, and frequencies along each stop.

The process is roughly as follows.

Initial inputs:-

  • A Shapefile layer (vector) describing the routes for the network, that you wish to transform into a GTFS timetable.
  • A Shapefile layer (vector) containing the stops along each of these routes.
    • (NB - we later created a script to auto-add stops at a given distance along the route. Need to document here).
  • Currently, we also need some auxiliary info as variables in a Python script:
    • Speeds of each transport mode (later, we want to update ability to be able to create this per-route, and even per-segment)
    • A specification of service frequencies throughout the day

TODO: document steps to transform this initial data into GTFS timetable.

Possible improvements:-

  • Variable speed per route (?). How exactly are we doing this currently. And could we create a script to modify the shapefiles so the speed on each segment is proportional to distance from the city, as L did for the Netview work?
  • Could we further automate and standardise the spatial database creation steps. And re-factor the scripts so they don't require superuser access (via sudo) to the machine you're running them on.
  • It would be good to possibly further refactor the nemtools and SimpleGTFSCreator scripts to better organise. Possibly to put them under a common special 'user' on GitHub.

Samples of headway definition

This is a headway definition over a day, so that there is 5 minutes frequency in peak hour, reducing to 10 minutes inter-peak, and 20 minutes late night and early morning.

default_service_headways = [
    (time(05,00), time(07,30), 20),
    (time(07,30), time(10,00), 5),
    (time(10,00), time(16,00), 10),
    (time(16,00), time(18,30), 5),
    (time(18,30), time(23,00), 10),
    (time(23,00), time(02,00), 20)
    ]
Cookies help us deliver our services. By using our services, you agree to our use of cookies.