DGT would like to be able to differentiate between an official and unofficial set of corridors/ramales in order to complete comparative analyses/overlay of the two sets of results.
o Could be documented as separate GTFS database files.
o Could be documented as different versions of the same route in the GTFS database.
From Metrobus training it became evident that Trip Pattern editing could be made simpler when you need to re-organise stop order along the route:
o Could have a dynamic table which populates on the right-hand sidebar so that as the trip pattern is being built, the order of stops lines up.
o You could then drag and drop the stop order, rather than having to click through each stop, which is really tedious.
Through Metrobus training session, it was clear that the language is still quite technical in a few places and could be tidied up:
o For example - “Zoom to trip pattern extent” could become “Show whole trip pattern” on the Trip Patterns tab.
o ITP / SETRAVI team to go through the full website and review terminology on button/website text to ensure it is in plain English, is sufficiently descriptive, and can be readily interpreted into other languages.
Can stops from other agencies be used? A stop may be common to both RTP and micro, to keep the stops file uncluttered it would be better to avoid having 2 stops in the same location.
When you create a new trip pattern and save, you then have to select it to start editing the stops. could it jump straight from saving the new trip pattern to being able to edit?
Important information about the station would be to note that there are specific features close to/at a station (e.g. a major bike parking station next door).
o Include in text description of station through TDM tool (short term).
o Create fields that will allow SETRAVI to encode the data onto the map (either through OSM, or through bike share routing / BikePlanner). Suggested fields are:
Wheelchair accessibility of stop/station (could be encoded in GTFS – Dhyana is in process of creating a pocket map to show accessibility of stops/stations).
Language needs to default to Spanish for Mexico City, and to other languages for other locations.
o Could be set by the coordinating agency (e.g. SETRAVI) in their administrator portal, and apply to all user accounts under their control.
o Could be customised / changed from default by individual agency staff, and their language preference remembered against their profile.
Some agencies want to be able to include routes and stops that are planned/proposed/future, rather than currently operating. As such, we need to create a tool which enables the agency to indicate whether the route/stop is operational (and should therefore appear in GTFS) or it is a proposed route/stop which should not.
From observing the training, people were moving the nodes associated with stops, meaning the routes no longer ran past the stops. Should these nodes be fixed to the stops?
STE suggested that they would like to be able to filter routes and stops out of the map view based on text search. Ideally they wanted to be able to show only one stop/route at a time in order to de-clutter the map.
o Text search for stops and filtering visually is relatively straightforward
o Text search for routes/lines and filtering visually is slightly more complex
SETRAVI can see all routes in the database, when the list is complete this will be quite extensive, could there be an option to filter these by agency to make individual routes easier to find.
The group demo showed problems when more than one person was trying to edit the same route. if a user is editing a route it should then be locked from others editing the same route.
DGT would like to integrate other fields of information derived from their MS Excel surveys that have been emailed out to the Colectivo operators. Eager to use these in order to help move the organisation of the network from one which is owner-operated to one with organised companies. Fields in the survey are:
o Route description (O-D + major stopping points).
o Route length in km / miles.
o Fleet size and vehicle type (no of vehicles and vehicle type) – required to inform analyses of whether smaller/larger buses could optimally operate on different routes.
Metrobus concerned that trip pattern timings could be misinterpreted if they are not heavily caveated, because they vary across time periods based on bus bunching at stops.
o Could be addressed through notes / comments attached to the trip time information contained in GTFS.
o Could be addressed by inputting cautious / conservative trip time estimates.
o Long-term, this could be addressed through Real-Time data which Metrobus could make available in a GTFS RT feed.
Want to be able to upload and export data from different sources (such as .SHP / .KML).
o Include support for data upload and export.
o Note that KML can be tricky to import, since it often requires cleaning.
o Open question whether an automated KML import tool is relevant (i.e. will it be used repeatedly), or whether it is a one-off effort every time.
o DGT / CTS EMBARQ has about 10% of all routes encoded in KML data (requested for them to share).
o Metrobus has additional KML data which will ideally need to be imported.
STE requested that it would be useful to toggle total/cumulative time of a trip along a trip pattern, instead of just showing the times against each stop