While OC Transpo provides a full set of GTFS data, the client can't be expected to us hundreds of megabytes to store the data. Plus, some data (such as shapes) aren't provided by OC Transpo and will need to be generated in another manner.
This is all data that will be stored locally on the client.
Required data
Stops
Routes
Relation between Stops and Routes (i.e. what Route stops at which Stop)
Route shape data
Stops
From the GTFS data the following will need to be included:
The stop ID, code, name, description(**?***), latitude, longitude, location type, and parent station.
The parent station values will need to be manually created since OC Transpo does not provide this information. Stations such as Hurdman with multiple platforms will need a new value for the "station" added (with location_type set to 1) and all child stops with their parent station values set to some id for the station.
* Might include stop descriptions for describing larger stops or stations where transfers can be made. Whether it will be worth the cost to maintain this info (since it will need to be manually updated) will be determined later.
Routes
From the GTFS data the following will need to be included:
The route id, short name, long name, type, service level, and color.
Short names will be filled in by the route's number (with the exception of R2). Long names can be generated from trip data, however this will need to be manually reviewed. Route colours will need to be manually inputted.
These indicate the general headings used by the routes. Service level indicates "frequent", "rapid", etc. rather than the route's type which refers to bus/rail.
Relation between Stops and Routes
Generated from trip and stop time data. Just a table with rows relating all stops to all routes. This allows the client to quickly get information on which routes serve nearby stops. This is only intended to be used by the app for locally displaying routes that serve certain stops, or for finding nearby routes. Any more complicated operations, especially ones depending on the time of day, should be done server-side using the stored trip data.
Route shape data
Loosely based on the shapes table from GTFS. Required values will be:
route id, shape id, shape data
The route id will refer to a route (the ID in the shapes and routes must remain updated to match!!). A route could have multiple shapes associated with it so we include shape ids. These shape ids will refer to values in the server's shape table and will be used by the trip planner in the future. The shape data itself will be sent and stored (on the client) as an encoded polyline for space efficiency.
Implementation
Data classes will need to be written to represent these data fields and their respective values. The model classes for sending this data to the client will also be written.
Server Data
The server will at all times maintain a full copy of the latest GTFS data in a database. This will be used by the server for other processes later on.
While OC Transpo provides a full set of GTFS data, the client can't be expected to us hundreds of megabytes to store the data. Plus, some data (such as shapes) aren't provided by OC Transpo and will need to be generated in another manner.
This is all data that will be stored locally on the client.
Required data
Stops
From the GTFS data the following will need to be included: The stop ID, code, name, description(**?***), latitude, longitude, location type, and parent station.
The parent station values will need to be manually created since OC Transpo does not provide this information. Stations such as Hurdman with multiple platforms will need a new value for the "station" added (with location_type set to
1) and all child stops with their parent station values set to some id for the station.* Might include stop descriptions for describing larger stops or stations where transfers can be made. Whether it will be worth the cost to maintain this info (since it will need to be manually updated) will be determined later.
Routes
From the GTFS data the following will need to be included: The route id, short name, long name, type, service level, and color.
Short names will be filled in by the route's number (with the exception of R2). Long names can be generated from trip data, however this will need to be manually reviewed. Route colours will need to be manually inputted.
These indicate the general headings used by the routes. Service level indicates "frequent", "rapid", etc. rather than the route's type which refers to bus/rail.
Relation between Stops and Routes
Generated from trip and stop time data. Just a table with rows relating all stops to all routes. This allows the client to quickly get information on which routes serve nearby stops. This is only intended to be used by the app for locally displaying routes that serve certain stops, or for finding nearby routes. Any more complicated operations, especially ones depending on the time of day, should be done server-side using the stored trip data.
Route shape data
Loosely based on the shapes table from GTFS. Required values will be: route id, shape id, shape data
The route id will refer to a route (the ID in the shapes and routes must remain updated to match!!). A route could have multiple shapes associated with it so we include shape ids. These shape ids will refer to values in the server's shape table and will be used by the trip planner in the future. The shape data itself will be sent and stored (on the client) as an encoded polyline for space efficiency.
Implementation
Data classes will need to be written to represent these data fields and their respective values. The model classes for sending this data to the client will also be written.
Server Data
The server will at all times maintain a full copy of the latest GTFS data in a database. This will be used by the server for other processes later on.