-
Notifications
You must be signed in to change notification settings - Fork 0
Manchester deployment
This chapter outlines Manchester specific requirements and challenges for the City Navigator.
Manchester GTFS data is currently lacking the shapes.txt file. These are required, so that the routes are drawn accurately on the maps presented to the end users. There are currently KML files including the route shapes. However, the lines in there files are disjointed, unordered and overlapping and therefore there is no easy way to convert this data to GTFS. The line start and end points should also match with the route start and end points.
Manchester does not currently have GTFS realtime data, so it is not possible to tell the user when the next public transport is going to arrive to a required stop. Manchester does now have a realtime API for the movement of the vehicles, however the API:
- is in a bespoke JSON format.
- Only covers the free city centre metro shuddle busses. There are legal problems to get the data for other bus routes operated by various private bus operators.
It would be possible to convert the current realtime data API output to GTFS realtime format, however this would require a prediction algorithm as well as would benefit from the data being available more frequently than currently.
At the moment only the bus network data is available in GTFS format. It would be good if in future this could be complemented with similar data from the train network and tram service.
It should be possible for the service providers (or any external parties) to skin the application in order to service effectively their target audience. The skins could be developed for various reasons: disabled transport skin, nightbus skin, days out with children skin... Maybe there could be even a library of skins for people to select from in order to use the application certain way easily. As well as ability to alter the visual look and feel, the skin would allow to highlight/limit the routes and POI datasets available within the application.
The application should allow various stakeholders to contribute point of interested data. CitySDK tourism API provides potential option and could be set up separately as the POI database for the city of Manchester. City navigator could then be an application using the POI database.
The application should be available either as an offline version or a text based low bandwidth version in case of bad network connectivity (this is quite common in the city centre areas in the UK due to high penetration of internet enabled mobile devices). The text based version might also be preferable for some users who digest better text based instructions than visualisation on a map. The text version can be complemented with voice instructions utilising technology such as http://espeak.sourceforge.net/languages.html.
The application runs as a web application and therefore must be hosted. The hosting environment must be reliable and resilient in order to ensure that the application is up and usage at all times. TfGM (Transport for Greater Manchester) is using Microsoft Azure and their preferred cloud hosting environment that can be scaled up on demand when required.
Our recommendation would be to start with one large Linux virtual machine in Azure (4 shared core CPUs and 7 GB RAM) and scale the service up from there as required.
This chapter lists the requirements in priority order, the most important requirement first.
- Hosting
- GTFS shapes
- Application skins
- Offline/low bandwidth usage
- POI Database using the CitySDK
- GTFS realtime
Resource:
Olli Aro & TfGM
Approach:
The hosting environment will be configured in Microsoft Azure.
The service will start with one large Linux virtual machine in Azure (4 shared core CPUs and 7 GB RAM) and we will scale the service up from there as required. Initially all service components are hosted on the same instance, however these can be separated to different instances later on when the demand increases.
The current list of the system components are their system requirements is as follows:
CORE NAVIGATOR APPLICATION
- Apache webserver.
ROUTING SERVICE
- Latest Java version.
CUSTOMISATION PORTAL
- Ruby 1.9
- MySQL
- Apache webserver
- Passanger
- RubyOnRais 3
POI SYSTEM AND API
To be confirmed
Resource:
TfGM & Olli Aro
Approach:
TfGM data team will work in order to release their route shape data in GTFS.
Resource:
Olli Aro
Approach:
Customisation portal web application will be developed allowing organisations to login and create skins for the application. The skins enable allows the creator to change the application look and feel as well as control which of the routing data and POI data should be highlighted and hidden. Creation of skins should not require any other technical skills than image manipulation and CSS editing skills for the most advanced tasks.
Skins can be saved in a catalogue, which case they can be selected from the core application or not which case the organisations would give special URL to their customers indicating which skin should be used for the application.
As well as for skins created by organisations, it is also possible for the individual users to use the customisation portal in order to personalise their city navigator.
The core navigation application is fully decoupled from the customisation portal, so that it is possible deploy the city navigator also without installing the customisation portal.
As a proof of concept we will develop a sample skin for the TfGM night bus service.
Resource:
Olli Aro
Approach:
This task will investigate first ways to optimise the performance and possibly serve offline the main application based on HTML5 and jQuery Mobile.
Based on the results from above, the task will either optimise the offline performance further with using native publishing frameworks such as Titanium SDK or develop a text only fast to download version of the navigator with possible voice instruction support utilising tool such as http://espeak.sourceforge.net/languages.html (or both).
Resource:
TBD
Approach:
CitySDK tourism API will be deployed as city wide POI system and API. The core application reads POI data from CitySDK. The available POI data will depend on the selected skin from the customisation portal or the core application configuration if the system has been deployed without the customisation portal.
Resource:
TBD
Approach:
TBD