Calgary Transit
Calgary Transit (CT) is the transit operator for Calgary. It operates 2 modes of transportation: light rail (CTrain), and buses (MAX bus rapid transit, BRT limited-stop buses, express buses and standard buses
As of late December 2021, approaching the new year, the Calgary Transit network remains scarcely mapped out. Calgary Transit provides an important service for the City, and creating a freely accessible and non-proprietary source of information on the network will have major societal value. This project was created to do just this.
A network tag preset is available for Calgary Transit bus stops and routes through the Name Suggestion Index (NSI), under "CT".
Why is this goal relevant to the community?
Competition - Being able to use routing services other than Google Maps or the Calgary Transit app is in of itself a bonus. If you don't like either of these apps, you now have more options. This is especially desirable among users of free and open source software.
Detail - Knowing where the nearest bus stop with a shelter and heating can be a blessing for people in a new area on a cold night. These details aren't provided via Google Maps or the Transit app.
Safety - Having a record of all the Calgary Transit numbers, including ones to discreetly report immediate safety concerns, widely available and easy to find on an offline maps app could help riders connect to resources to improve the safety of the transit network. Currently, you'd be lucky if you needed to find the number to discreetly report an immediate safety concern if it wasn't posted anywhere nearby, you don't have it saved to your contacts and you don't have an internet connection. You shouldn't need to pay for data or for a car in order to feel safe in our city.
Bus Stops
The first and foremost task of mapping out the entire transit network starts with mapping out every bus stop.
Ideally, every bus stop would be tagged with the following keys:
Regular bus stop
highway=bus_stop, public_transport=platform, bus=yes, network=CT, network:wikidata=Q143630, network:wikipedia=en:Calgary Transit, network:wikipedia:fr=fr:Calgary Transit, operator=Calgary Transit, shuttle_bus=*, name=*, bus_routes=*, ref=*, shelter=*, bench=*, bin=*, advertising=*, surface=*, lit=*, tactile_paving=*, departures_board=*, heating=*, active=*
Future bus stop
public_transport=platform, bus=yes, network=CT, network:wikidata=Q143630, network:wikipedia=en:Calgary Transit, network:wikipedia:fr=fr:Calgary Transit, operator=Calgary Transit, amenity=sign, name=Future Bus Stop
Bus zone
public_transport=platform, bus=yes, network=CT, network:wikidata=Q143630, network:wikipedia=en:Calgary Transit, network:wikipedia:fr=fr:Calgary Transit, operator=Calgary Transit, amenity=sign, name=Bus Zone
If there's more than one sign, and hence more than one ref number for a stop, you can separate these values with a pipe or a semicolon, but not a comma. This is done because having one node per ref as opposed to one node per stop would create a lot of duplicate information. Optionally, every stop node may include a bus_routes tag, with every route number that stops there separated by a pipe or semicolon, but not a comma. This could be used by on-the-ground mappers to indicate which bus route relations the node should be a part of, so computer using editors can make the necessary changes.
The position of the bus stop node should be the position of the pole, but the node represents the entire platform. A line or area object can be created for the platform, with the name equal to the stop name (or ref). All other attributes can be looked up by looking at the node with the same name.
If a bus stop needs to be edited or corrected by another mapper, you can add a fixme tag to the node. This can make it much easier for mappers to search for and correct the stops that need changes using tool like Overpass Turbo.
While it may be tempting to add a direction tag to a bus stop node, it's important to remember that any given stop may have many routes associated with it. As such, a direction cannot be attributed to the stop itself, but to the stop in relation to the route. Therefore, direction information will be added once we add routes to the map. When direction information can be added to a stop, the direction must match the direction specified in the name. For example, bus stop names that begin with EB are Eastbound.
Progress
| As of date | Completely mapped with all above tags (green) | Mapped with ref, but not all other tags (yellow) | Missing from OSM (red) | Mapped in OSM but ref not specified (purple) | More than one stop with the same ref (blue) | Total active stops | Map |
| Jul 2023 | 7 | 932 | 4959 | 464 | 7 | 5889 | |
| Mar 2023 | 7 | 932 | 5294 | 464 | 6 | 6243 | |
| Feb 2023 | 0 | 939 | 5289 | 462 | 6 | 6238 | |
| Jan 2023 | 0 | 939 | 5289 | 470 | 6 | 6238 |
Routes
For a list of all routes and progress, see Calgary Transit/Routes.
Importing from City of Calgary Open Data
It's important to remember that OpenStreetMap is a community project, a standalone dataset, not a series of augmented datasets. With map history, version control, copyright and community health all being very important, we need to be cautious about the way we work with our own data, and especially the data of others.
As of right now, importing data from any external source isn't a supportable option so long as we continue to have duplicate stops and stops without refs in OSM. It may be tempting to propose deleting all bus stops in Calgary and replacing them with imported data, but this would be a very destructive action because one cannot do proper node version control this way, and it'd delete all extra tags that aren't present in the external dataset being imported, meaning information that may not exist anywhere else may be forever lost to time if not rolled back.
My proposition is that all stops within OSM that do not contain a ref tag should be mapped manually, in-person, and all duplicate nodes should be figured out and accurately mapped before we consider importing data. This would ensure that the only data we would need to import is simply missing from OpenStreetMap, and keeps the map as it exists now in a simpler state, so that way once we do the import, any additionally created untagged and duplicate nodes could be dealt with quickly and easily. If we cannot manage the map in its less thorough state, then we surely wont be able to once we add about five thousand additional nodes to it. Once the map is ready for importing external data, the only data that should be imported are all nodes missing in OSM. Any nodes and other data that exist already in OSM should remain completely untouched.
