v2025.08

What's Changed

The following updates were made to improve the data that goes into the BikeSpace parking map:

Update bicycle_parking status handling by @tallcoleman in #17

• When we update data from the City of Toronto Open Data portal or OpenStreetMap, we record a couple basic things such as when the data source says it was last updated and how many entries there are in each dataset. These used to be written into a JSON file that only showed the stats from the most recent update, but are now added to a CSV file where you can see the trends over time.
• If you want to see the status log for the bicycle_parking dataset, you can view it here: bicycle_parking/statuses/bicycle_parking_statuses.csv

Improve deduplication by @tallcoleman in #18

• Much of our previous de-duplication between OpenStreetMap and City data relied on the operator= tag, but this tag is usually not filled in by OpenStreetMap contributors. To improve the de-duplication, the script now omits any OpenStreetMap feature that is likely to be a City ring and post and that is within 5m of a known City ring and post. This removed approximately 600 duplicate features from the displayed data.
• Occasionally, there are City of Toronto bike parking features mapped in OpenStreetMap that are not in the City of Toronto data (a common example is ring and posts or racks installed by the City parks department). To account for these, the script now keeps OpenStreetMap features tagged as being operated by the City if there is no known City feature within 30m.
• Why 5m and 30m? These are the same distances used by our clustering logic, based on past testing to maximize matches while avoiding false positives. For the 5m match, the locations for the City dataset that includes ring and posts are very accurate, so a small search radius catches most duplicates. Other City datasets are address-geolocated, so the larger 30m radius is required to confirm that there is not a match between OSM and City features.
• There is a new output file, output_files/all_normalized_tagged.geojson that shows the intermediate steps that go into the de-duplication logic. The properties starting with _ show the checks considered and _retained shows the final result about whether to keep or drop a feature. This helps make it easier to understand why individual features are included or omitted from the map and fix errors.
• City bike lockers used to be de-duplicated based on a proximity search of 200m (the radius was unusually large because the locations in the City data are not very precise). Locker de-duplication is now based on a ref tag, similar to the other datasets. Adding ref:toronto.ca:lockers:title= to an OpenStreetMap feature will ensure that the OSM feature replaces the City feature in the displayed data. The title values can be looked up on the City's locker locations page.

Improve cluster property summarization functions by @tallcoleman in #20

• Currently, some City of Toronto features are clustered together into a single point on the map. Ring and Posts within 5m of each other are clustered together to improve usability and reduce the size of the data that needs to be loaded by the parking map. City bike racks from different datasets within 30m of each other are clustered together since they may be duplicates.
• When features are clustered together, their property values need to be combined. Previously, values that should be concatenated (e.g. ref ids) were joined together with semicolons per OpenStreetMap tagging norms. Other values that varied between features were simply listed, separated by the | character.
• Now, values that vary between features are summarized in a more concise way, with counts of each unique value encountered. For the covered= tag, where values are essentially boolean (i.e. yes, no, or null), a single tag is generally returned based on the input values. E.g. all yes would return yes, some yes and some null would return probably yes, and some yes and some no would return maybe. All of the summarization functions and the concatenation function now have more robust handling of null values and edge cases.

In addition to the changes noted above, the code was re-organized and cleaned up and more test coverage was added, especially for added or changed functionality.

Full Changelog: v2025.07...v2025.08