Commit Graph
17 Commits
Author SHA1 Message Date
Cliff Flood 68e99d9407 docs: list the Ontario regions in the README feature table
The Transit row names the regions a reader can expect to see vehicles in,
and still stopped at South East Queensland after nine Ontario feeds were
added. Someone scanning the table for Toronto would have concluded the
layer does not cover it.

Toronto carries the subway caveat here too: the row would otherwise
promise metros in a city whose metro publishes no positions.
2026-10-15 20:18:21 -04:00
Cliff Flood 9ab26bbcb0 docs: record Hamilton's route table and the feeds left out
Two gaps. The Hamilton entry never said its route ids are internal keys,
which the Guelph, Burlington and YRT entries all say of theirs; the
route-table sentence in the transit notes named those three and not
Hamilton, though it now carries the largest table of the four. Both were
stale the moment Hamilton got a table.

The exclusions were half-recorded: GO Transit and Grand River had their
reasons written down, but Ottawa, London, Thunder Bay and the static-only
majority did not, so a later reader would have re-investigated feeds that
were already surveyed and rejected. All of them are now named with the
rule each one falls to, and the survey is stated as complete against the
Mobility Database's Ontario catalogue.

Also records that a route label is never invented, which is why YRT's
unpublished 9101 renders as the feed sends it.
2026-10-15 20:18:21 -04:00
Cliff Flood 65ac2d37fb feat(transit): name Hamilton's routes, which ship as internal keys
Not one of HSR's 80 route ids equals the number on the bus. Hamilton was
registered without a routeLabel, so every vehicle in the city read as
"Route 5783" where a rider would say 5 DELAWARE — 228 of them in an
afternoon sample. The mechanism to fix it already existed and simply was
never pointed at this feed.

Two details the table cannot skip:

Hamilton runs two generations of route id at once. `5688` and `5780` are
both the 2 BARTON, and both arrive in the live feed, so both are listed.
That is why 80 ids collapse to 46 distinct routes.

The seasonal and event shuttles publish a name where the local routes
publish a number — TC230, PEACH, ROCKTON. Those are already what a rider
would say, so they survive as published rather than being forced into a
number they do not have. Numbers are unpadded to match the rest of the
registry: routes.txt says `02`, a rider says 2.

Ids and names are from the City's own published GTFS routes.txt, which
sits under the same open-data licence as the realtime feed. Checked
against the live feed: all 30 route ids in service translate, none fall
through.
2026-10-15 20:18:21 -04:00
Cliff Flood 007562c6c8 docs: note the Ontario transit feeds in the changelog
CONTRIBUTING asks that a runtime behaviour change update CHANGELOG.md in
the same PR. Nine new feeds and two new label mechanisms qualify.
2026-10-15 20:18:20 -04:00
Cliff Flood 4ffbdda3f5 feat(transit): name YRT's local branch routes
YRT encodes a branch as a two-digit suffix on the base route id. The Viva
table already depended on that scheme — `60102` is Viva Blue's B branch —
but local routes were passed through whole, on the reasoning that a YRT
route id is already the number on the bus. For a plain route it is. For a
branch it is not: a rider watching route 83's B-branch bus saw "8301".

A 15:41 EDT sample of the live feed found four branch ids in service.
Three are published in York Region's GTFS `routes.txt` and are named here
from it, unpadded to match the local routes beside them (the file says
`083A`; the registry has always preferred `105` to `005`):

    10702 -> 107B   KEELE
    8301  -> 83A    TRENCH
    9002  -> 90B    LESLIE

The fourth, `9101`, runs in the realtime feed but appears nowhere in
`routes.txt`. The pattern all but spells "91A" and that is precisely why
it is absent: the registry translates published names, it does not infer
them. It stays opaque until York Region publishes it.

Renamed YRT_VIVA_ROUTE_NAMES to YRT_ROUTE_NAMES, since the table is no
longer only about Viva.
2026-10-15 20:18:15 -04:00
Cliff Flood a7fc5ea7c5 feat(transit): add Burlington, switch Barrie and YRT on
Burlington's route ids are internal keys with a trap in them: `351` is
route 1 while `3510` is route 10, so no prefix trim is correct and the
table is a real join against the City's own published GTFS. Its licence is
the same 2011 municipal template as Mississauga — revocable, and the terms
must travel with the data, so licenseUrl is the terms document itself.
Plain http:// has no listener at all, so https is mandatory, not preferred.

Barrie and YRT ship on. Both operators invite acceptance of their licence
through a form, and both licences also state that use is itself acceptance
("By using Barrie Transit Data, you agree to be bound by these terms";
"Your Use of Information indicates Your acceptance"). This deployment
relies on that clause, and both entries record it so the reasoning does not
have to be re-derived.

Nine Ontario feeds now, all verified live against their upstreams.
2026-10-15 20:18:15 -04:00
Cliff Flood 8ccb0cd895 feat(transit): register YRT/Viva off, named by Viva colour
York Region's feed is first-party infrastructure under an open licence that
permits commercial use and does not even require attribution. It is the one
feed that fills the gap north of Toronto, and it is switched off anyway.

The operator asks that its licence be accepted through a form collecting a
name, company, phone and email. No credential is issued and nothing gates
the endpoint — the licence body says use is itself acceptance — but a form
asking for contact details is close enough to the registration this registry
refuses that a person should decide it, not a poller. Barrie is off for the
same reason. Both are one line from on.

Viva route ids get labels: YRT publishes `601` where every station sign says
Viva Blue. The numeric local routes already read correctly and carry no
entry, so the table is six lines, not 125.

No vehicle in this feed carries a bearing; heading comes from observed
movement, as with Durham.
2026-10-15 20:18:15 -04:00
Cliff Flood 11dd914c2f feat(transit): add Guelph and Kingston, register Barrie off
Guelph's feed publishes the internal database key of a route (`2991`)
where the rider sees the number on the bus (`1`), which would have put
"Route 2991" on the label a person reads. So a feed may now carry its own
`routeLabel`, the same way it may carry its own `modeWords`. Guelph's table
is its 33 routes, taken from the City's own published GTFS; an id missing
from it renders unchanged, because a raw id you can compare against the bus
beats a blank. Every other feed is identity and carries no table.

Kingston is catalogued by the City against this exact URL. Its licence PDF
link is pinned to the canonical location rather than the legacy path that
currently redirects there — Durham's entry records what happens when such a
redirect is eventually dropped.

Barrie ships REGISTERED AND OFF. The City offers its licence for acceptance
behind a click-through gate, and nobody on this project has accepted it.
Whether to accept is a person's decision, not an assumption a poller should
make, so the feed is visible, documented, and one line from enabled.
2026-10-15 20:18:15 -04:00
Cliff Flood 849cb80375 feat(transit): add MiWay, Hamilton HSR and Durham Region Transit
Three keyless GTFS-Realtime feeds around Toronto, each verified live: all
vehicles carry real coordinates, and each is polled only near its own
region rather than across the Golden Horseshoe.

The licences differ in ways the registry now records rather than flattens:
Hamilton PRESCRIBES its attribution wording, so the credit is that exact
sentence; Durham makes credit optional and its catalogued licence PDF is
dead after a site relaunch, so licenseUrl points at the live page where the
v.1.0 text was actually read; Mississauga's licence is revocable and asks
that the terms travel with the data, so licenseUrl is the terms themselves.

All three are bus-only and set no route hint, so their modes default rather
than resolve. Durham publishes no bearing on any vehicle — heading comes
from observed movement, as with any feed that omits it.

GO Transit / Metrolinx stays out: its feed requires an API key.
2026-10-15 20:18:15 -04:00
Cliff Flood 9fc4a5ac04 feat(transit): let a feed name its own modes, and call TTC trams streetcars
A Toronto 501 and a Helsinki 1010 are both the `tram` mode. Only one of
them is called a tram by the people who ride it, and the detection label
is documented as "what a person standing at the stop would call it".

So the mode stays shared — same silhouette, same speed limits — and a
registry entry may carry `modeWords` naming the modes it runs. Everything
without an override falls through to the shared table, so this renames one
word for one operator and nothing else.

Threading the feed to the detection metric needed a resolver in queries.js,
since the cached-contact path has only the entry. It answers from live feeds
first, so a feed disabled mid-session stops supplying vocabulary.
2026-10-15 20:18:15 -04:00
Cliff Flood c5f7fe285b feat(transit): add the TTC Toronto surface feed
TTC BusTime publishes keyless GTFS-Realtime VehiclePositions with real
coordinates for the surface network: ~1,180 buses and streetcars with
bearing and per-vehicle timestamps. Registering it is one registry row.

The subway is deliberately absent. BusTime covers surface vehicles only
and the subway publishes no positions, so Lines 1/2/4 are left out rather
than inferred from schedules — the same rule that keeps NYCT out.

Route numbers establish the mode: the three-digit 500-series is streetcar,
as are the four Blue Night routes on streetcar trackage. A leading 5 alone
would misclassify bus routes 50-59, so the rule is anchored and tested.

Licensing is the portal-wide Open Government Licence - Toronto; the CKAN
record for the BusTime NVAS dataset leaves its own licence field blank,
and the terms note says so rather than overstating the grant.

Refs #70
2026-10-15 20:18:15 -04:00
Cliff Flood 001043f74e fix(bikeshare): let one dead city feed fail without failing the layer
The layer recorded failure in a single `_error` string. Every city feed is
fetched independently, so one retired operator set that flag for the whole
layer — and the only code that cleared it ran on a successful *activation*,
which `runProximityCheck` skips for a city that already has rendered points.
A dead feed that re-entered camera range therefore set the flag on every
camera move and nothing ever cleared it: a permanent LOAD FAILED over a map
drawing every other city's stations.

Failure is now tracked per city in `_failedCityIds`, and `getStats()` reports
it only when the failures left nothing to draw. A city that recovers removes
its own entry rather than waiting for a neighbour to succeed.

This was reachable only because Buffalo sits 95 km from Toronto, inside the
100 km activation radius — the one dead city in the registry with a healthy
neighbour in range. The other four failed alone, where LOAD FAILED with an
empty map reads as correct, which is why the latch went unnoticed.

Probing all 33 registry systems found five dead. Three had moved and are
repointed: Reddy Bikeshare (Buffalo) to Social Bicycles, Tugo (Tucson) and
Trinity Metro (Fort Worth) to PBSC, all verified serving stations. Two are
dropped because the systems wound down rather than moved — Broward B-cycle
404s at every documented endpoint, and CoGo's replacement Lyft feed publishes
zero stations with status last reported in March 2025. `gbfs.cogobikeshare.com`
no longer resolves, so its allowlist entry goes too.

All 31 remaining systems were verified live, and every registry URL was
checked against the proxy host and path allowlists.
2026-10-13 18:55:20 -04:00
Cliff Flood b8ccfd1648 feat(bikeshare): add Bike Share Toronto
Toronto runs the same PBSC platform as the Austin, Honolulu and
Chattanooga systems already in the registry, and publishes the identical
GBFS v2 endpoint pair under `toronto.publicbikesystem.net`. The proxy
allowlist already admits the host through its `*.publicbikesystem.net`
wildcard and the paths end in the expected `station_information.json` /
`station_status.json`, so the system needs no new plumbing — only the
registry entry that names it.

Verified against the live feeds: 1,069 stations in both documents, all
1,069 joining on `station_id`. The layer reads `num_bikes_available`,
which Toronto populates normally, so availability renders without a
vendor-specific mapping. It does not populate the standard
`num_bikes_available_types`, reporting per-type counts under PBSC ids
(ICONIC/BOOST/EFIT/ASTRO) instead; nothing reads that field today, and
this entry deliberately does not translate it rather than adding a
mapping with no consumer.

The center is downtown at 43.6532, -79.3832 with the group's 90 km load
radius. The stations span roughly 37 km east-west, from Etobicoke to
Scarborough, so a tighter radius would drop the outer ends on a downtown
pan.

The new registry test is the reason this was cheap to be sure about: it
holds every city's feed URLs against the same host and path predicates
the proxy enforces, so a city the proxy would silently refuse now fails
the suite instead of rendering an empty layer.

Credited to Bike Share Toronto (Toronto Parking Authority). The City's
open-data package declares no licence and the feed publishes no
`license_url`, so it is treated as attribution-only, like the other GBFS
operators, rather than claiming a licence that was never granted.
2026-10-13 18:55:20 -04:00
Cliff Flood fc2c372ffc fix: keep install assets inside a non-root base
Manifest start_url, scope and icon src resolve against the manifest URL,
so root-relative values sent an app served under a path prefix to the
domain root. Make them relative, and add a build test under
base: '/example/' that asserts every emitted link and manifest URL stays
inside the base. index.html is unchanged: Vite already rewrites its
links under base.
2026-10-13 18:54:59 -04:00
Cliff Flood 7bdeff06a9 fix(cctv): base the Toronto ground prior on the city's real relief
The pack shipped a flat 90 m. Sampling a DEM at all 336 camera sites puts
the network between 76 m (Queens Quay) and 209 m (Keele & Steeles), mean
116 m: a median error of 14 m against the old value, 88 m at the 90th
percentile and 119 m at worst, with the Allen Road cameras — 170-197 m —
the furthest underground.

No constant fits a city with that much relief; the precomputed ground
heights are what place a camera properly, and until this pack has them the
prior is the fallback for a sidecar miss or an edited pose. The mean is at
least wrong in both directions rather than only one.

This value is not part of the served pose, so it changes no pose hash and
invalidates no precomputed entry.
2026-10-13 18:54:59 -04:00
Cliff Flood 51b89d3e4a feat(cctv): add the City of Toronto RESCU camera pack
The province's 511 pack covers Ontario's highways; this adds the municipal
network underneath it — roughly 336 cameras across downtown arterials plus
the Gardiner, DVP, Allen and Lake Shore, from the City's own open data.

The list is keyless and carries no frame URL, so frame URLs are built from
the convention the dataset documents (`CameraImages/loc####.jpg`) and a
camera number validated as plain digits. The frame proxy is therefore
pinned to the portal origin by construction rather than by trusting a
field. The list fetch refuses redirects, bounds the body it buffers, and
releases the transport on every rejection path.

The dataset publishes no camera facing. `D1`-`D4` look like a compass and
map trivially onto one, but they describe the *comparison* images — static
reference stills captured in 2016 and served from a different path — not
the live pan-tilt-zoom frame. A heading derived from them would be
confidently wrong for every camera in the city, so every camera takes the
shared id-hash fallback at low confidence, as headingless Austin, TfL,
Fintraffic and Calgary cameras do. A test pins that down so it is not
"fixed" later.

Names stay verbatim: the feed's labels are upper-case, and title-casing
would mangle MCCOWAN RD and ST HELEN'S AVE more often than it helped.

Carries the Open Government Licence – Toronto attribution the licence
requires. Disable with `CCTV_TORONTO_ENABLED=0`.
2026-10-13 18:54:59 -04:00
Cliff Flood bdd64660e7 feat: ship a web app manifest and home-screen icons
Adding the app to a phone home screen produced a blank tile: index.html
linked only an SVG favicon, and Safari ignores SVG for apple-touch-icon,
substituting a screenshot of the page. There was no manifest at all, so
Android had nothing to install against either.

Generate the rasters from public/logo.svg with sharp, which the repo
already carries. The output is committed so a plain `vite build` needs no
image toolchain; re-run scripts/generate-icons.mjs after changing the
logo. The logo's viewBox is wider than it is tall, so each icon centres
the mark on a square #0a0a0f canvas rather than stretching it, inset to
78% normally and 54% for the maskable variant to survive Android's
circular crop.

The SVG favicon stays as the browser tab icon.
2026-10-13 18:54:58 -04:00