Toronto Parks Layer
Turns the City of Toronto Green Spaces
dataset (~1,750 park-ish polygons) into map-tile layers that OpenStreetMap
mappers can add to the JOSM and iD editors as a reference overlay.
Live layer and how to add it: https://skfd.github.io/toronto-parks-layer/
It is a sibling of
toronto-addresses-layer and
toronto-waterways-layer:
the same download -> slim -> tiles -> site -> publish pipeline, pointed at
the Green Spaces polygons. (The City's older "Parks" dataset is deprecated;
its page redirects to Green Spaces.)
What it produces
- Vector tiles (MVT) — interactive in iD; click a polygon to read its
name, class and area_id tags.
- Raster tiles (PNG) — translucent green fills with park-name labels;
each park's outline and label share a stable hashed colour (as in the
addresses layer) so a name overhanging a small polygon is still visually
tied to it. A readable backdrop for JOSM. A name only renders once
the polygon is a visible shape on screen (the text may overhang small
polygons), so big parks are labelled from city zoom and small parkettes only
when zoomed in; at the top raster zoom every named park is labelled.
- A landing page with copy-paste "add this layer" instructions for both
editors.
- A gap-review page (
/gaps/)
that compares the City polygons against
park areas already in OpenStreetMap and lists the gaps — City parks with
no overlapping OSM area ("missing"), matched parks whose OSM name differs
("mismatch"), and matched parks tagged both leisure=park and
landuse=recreation_ground ("retag") — on an interactive map and a
filterable table, with
OSM / iD / JOSM links per row (the JOSM link needs JOSM running with
Preferences → Remote Control enabled). OSM areas
are pulled from Overpass; matching is by the area the polygons really share,
with landuse=allotments accepted only for the City's gardens (see
src/compare.py). Its
history page
charts those counts over time, one point per weekly run. Matched parks whose
outlines disagree are listed apart as "worth a look", most disputed first and
off by default. They are prompts to compare two shapes, not gaps, so they stay
out of the gap counts and the chart.
All of it is published to GitHub Pages and rebuilt weekly.
What is kept
Green Spaces classes kept by the slim filter (INCLUDE_AREA_CLASSES in
src/config.py): Park, Open Green Space, Golf Course,
Cemetery, Civic Centre Square and their OTHER_* variants. Traffic
islands, road slivers, boulevards, hydro corridors, building grounds and the
generic administrative OTHER_* classes are dropped. Names are converted from
the City's ALL CAPS to title case.
The numbered TRCA LANDS ( n) parcels are kept out of the rendered tile layer
(they are conservation-authority land, not real named parks). The slim step
writes them to parks-slim.geojsonl but not to parks-layer.geojsonl, so the
gap-review page still tracks them while the tiles do not.
Setup
- Install Python dependencies:
pip install -r requirements.txt
- Set up WSL2 + tippecanoe once — see wsl-setup.md.
- Confirm the GitHub repo in
src/config.py (GITHUB_REPO, PAGES_URL).
Usage
python run.py download # fetch the latest Green Spaces GeoJSON (smart-cached)
python run.py slim # filter to park-ish polygons -> slim GeoJSONL
python run.py compare # diff City polygons against OSM -> data/gaps.geojson
python run.py backfill # one-off: reconstruct past weeks' gap counts from OSM history
python run.py vector # build vector (MVT) tiles via WSL tippecanoe
python run.py raster # build labelled raster (PNG) tiles
python run.py site # render the landing page (+ the gap-review page)
python run.py publish # force-push the site to the gh-pages branch
python run.py build # download + slim + compare + vector + raster + site
python run.py update # build + publish (the scheduled entry point)
Build output lands in build/site/; that directory is what gets published.
Tile endpoints
https://skfd.github.io/toronto-parks-layer/tiles/vector/{z}/{x}/{y}.pbf (z10-19)
https://skfd.github.io/toronto-parks-layer/tiles/raster/{z}/{x}/{y}.png (z13-17)
The vector layer name is parks.
Hosting
The tile pyramid is published to an orphan gh-pages branch, recreated and
force-pushed on every build so repository history never grows. One-time step:
in the GitHub repo, set Settings → Pages → Source to the
gh-pages branch (root).
Scheduling (Windows)
Run as Administrator:
.\schedule-add.ps1 # registers a weekly task "kk-TorontoParksLayer", Mondays 16:30
.\schedule-remove.ps1 # unregisters it
Weekly is enough — the City refreshes the Green Spaces dataset monthly, so
the tiles rarely change; it is the gap page, which diffs against live OSM, that
moves week to week. 16:30 keeps the build clear of the daily address-layer task.
The task runs python run.py update and appends output to logs\scheduler.log.
The link gate
Both network steps — the dataset download and the gh-pages push —
run behind addressvault.net, the same offline/metered gate the address vault
pulls behind. A dead link is not a build failure: run.py exits 75
(EX_TEMPFAIL), nothing is written, and the task's restart-on-failure retries
three times half an hour apart rather than leaving a seven-day gap. It does not
wait the link out, since the task carries a hard ExecutionTimeLimit that would
kill a long wait anyway.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
