Guelph/Address Import/Continuous

A subpage of Guelph/Address_Import because this is a continuation of that import, not because it is maintained by its author. The parent page is ARandomThumbtack's and stays theirs; this subpage is written and maintained by skfd, who is solely responsible for everything proposed on it. Neither page speaks for the other.

Status

• Stage: Proposed. The community feedback window opens with the publication of this page and the accompanying Community Forum announcement.
• Last revised: 2026-08-27
• Contact: guelph@comentality.com
• OSM import account: skfd imports — the same dedicated account used for the Toronto address import. The maintainer's personal account (skfd) is not used for any upload from this tooling.
• Discussion: OSM Community Forum thread #135103 — the 2025 import's own thread, tagged import / import-proposal, where this proposal was announced rather than in a new topic. The announcement venue under the current OSM Import Guidelines.
• Tooling: address-importer-friend (engine) + guelph-address-import (this city's config) + ontario-address-changes (source tracker).
• What this page is: a continuation, not an initial import proposal — and short for two reasons, both of them deference rather than brevity for its own sake.
  • Guelph's address import already has a page. Guelph/Address_Import establishes the dataset, the licence, the tag mapping and the community consent, and it is not superseded by this one. Everything settled there stays settled; this page records only what changes when upkeep becomes continuous and passes to a different maintainer.
  • The machinery already has a page. The conflation algorithm, review UI, check suite, audit log and revert plan are unchanged from Toronto/Import/AddressPoints — reviewed by the community in May 2026 and used for 1,297 production changesets.

So: read Guelph/Address_Import for what Guelph's import is, Toronto/Import/AddressPoints for how the tooling works, and this page for what is different now. A reader who needs neither should be able to finish this page in a few minutes.

Credit where it is due

Guelph's civic addresses were already imported, solo, by ARandomThumbtack_Import between 2025-09-16 and 2025-10-23, from the same City of Guelph open dataset, documented at Guelph/Address_Import and finished ahead of their own self-imposed deadline. It is careful, well-tagged work: the changesets carry import=yes, import:page, source and source:license, which is more than most bulk address edits in Ontario manage, and it is the reason Guelph is one of only two municipalities in a 42-dataset Ontario survey with address coverage above 90%.

Thank you. This proposal exists because that import worked, not because it did not. Nothing here revisits, re-imports or supersedes it — Guelph/Address_Import remains the record of the original import and belongs to its author. What follows is maintenance layered on top of finished work.

ARandomThumbtack was contacted before this page was written and is content for the maintainer to take on continuous upkeep; they are invited onto the reviewer roster below, and they retain a standing veto over anything touching Guelph addresses.

What is proposed

Continuous, human-reviewed gap-fill of the civic addresses the City publishes and OSM does not yet have, re-run each time the City's dataset changes — plus the QA findings that fall out of running conflation over a city that is already mapped.

Alongside it, and consented separately, two one-off mechanical tag cleanups on Guelph's existing address objects: removing addr:province=Ontario, and splitting the unit back out of double-encoded housenumbers. Both are described in § Mechanical edits. They are not part of the import path and nothing in the import depends on them landing.

Guelph's import is finished. There is no initial upload left to argue about — the questions an initial proposal exists to settle (is the dataset suitable, is the licence compatible, does the community want it) were asked and answered on Guelph/Address_Import in September 2025. What was never settled is who keeps it current afterwards, and that is the only thing this page proposes.

The contrast with Toronto/Import/AddressPoints is one of proportion, not of kind. Toronto is maintained continuously too — but there the continuous part is a trickle behind a half-million-address bulk rollout, and its page is long because, in 2026-05, everything was still open. In Guelph the trickle is the entire job, and almost nothing is open.

Scope

Measured against source snapshot 39 (2026-08-13): 53,846 active source rows, collapsing to 40,634 civic addresses.

Item	Figure	Disposition
Civic addresses missing from OSM	2,523 of 40,634 (6.2%)	Candidates for upload; hand-measured via Overpass, 2026-08-10. Diffuse — there is no unmapped district. These are the tail the original import parked in RemainingAddresses.osm, plus everything the City has published since October 2025.
New addresses per City update	small, unknown	The recurring workload this proposal is actually about. Tracked snapshot-to-snapshot by ontario-address-changes.
Unit-level addresses	13,162 source unit rows	Not uploaded. Source rows are collapsed to one candidate per civic address ([units] policy = "collapse-to-civic"). Guelph's units are largely already in OSM, double-encoded — see § Mechanical edits.
Street-name disagreements	to be reported	Output of the nearby_street_mismatch check. Reported, never auto-corrected.
OSM-only addresses	to be reported	Addresses OSM has and the City source does not. Never deleted — see non-goals.

Goals

• Keep OSM's Guelph civic-address coverage current against the City's roster, continuously, rather than as a one-off.
• Surface disagreements between OSM and the City source — street names, positions, duplicates — to local mappers as reviewable findings.
• Preserve a per-candidate audit trail (source row → verdict → reviewer decision → changeset id → resulting OSM id), as in Toronto.

Non-goals

As § Non-goals of the Toronto import, with one deliberate exception:

• No deletions of objects, including addresses the City source no longer lists.
• No mutation of existing OSM objects by the import. The import path creates new nodes only. The two campaigns in § Mechanical edits are the sole exception, they are announced and consented separately from the import, and they touch only the two tags named there — nothing else on the object, and no geometry.
• No unit-level addresses uploaded, no addr:interpolation cleanup, no polygons, no geometry editing.

Import data

Dataset and licence are unchanged from Guelph/Address_Import and are not re-litigated here: City of Guelph address points (explore.guelph.ca) under OGL-Canada-2.0, which that proposal established as ODbL-compatible. Attribution is satisfied by addr:source on the node and source on the containing changeset (see § Tagging plan for why the node key differs from the 2025 import's). What follows is only what a continuous consumer adds.

• Consumption path: the City feed is snapshotted into SQLite by ontario-address-changes, which diffs consecutive snapshots. That diff is what makes "continuous" cheap — each cycle re-conflates the whole city, but the review queue is normally only what changed.
• OSM side: Geofabrik Ontario PBF, re-pulled before each cycle. If more than 24 h elapse between conflation and upload, re-fetch and re-conflate.
• Review partition: the City's 23 "Guelph Areas" community polygons (AREA_NAME), covering 99.47% of source points. The 287 orphans — city-edge cases plus the 75 Guelph/Eramosa Twp rows, which lie outside the city fabric by construction — are reviewed as a final catch-all batch rather than skipped; see § The Guelph/Eramosa rows.

The Guelph/Eramosa rows

The City publishes 75 rows past its own boundary, tagged PLACE='Guelph/Eramosa Twp', and Wellington County publishes the same corner. Earlier drafts of this page held them back pending a decision on which source should own them. That decision was already made on the ground in 2025: 73 of the 75 are in OSM today, imported from the City source by ARandomThumbtack_Import in changeset 172765115 (2025-10-02). They are treated here as city-sourced, like the rest of the roster.

A row-by-row comparison of the two sources (City snapshot 2026-08-30 against County snapshot 2026-08-29) found almost nothing to choose between them, and nothing that argues for switching:

• 73 of 75 match exactly on (number, street), with no unit and no street-name disagreement — both sources already publish OSM long form. Coordinates differ by a median of 9 m.
• Neither source has changed any of these 75 in the 80 days both are tracked; the County's 73 are still on their first observed version.
• Wellington publishes nothing that collides with the City's other 53,771 rows: no County row shares a (number, street) with a city row within 100 m. This corner is the whole of the overlap.
• 664 Woodlawn Road East (the Guelph Lake Sports Fields) exists in the City source only. Wellington carries no Woodlawn Road East at all — outside the city that road is Wellington Road 124 — and its nearest address is 662 m away. Routing these rows to the County would lose it.
• Two of the 75 are missing from OSM and are ordinary gap-fill: 664 Woodlawn Road East and 2 Promenade Road.

One genuine conflict remains, and it is small: the City's 672 Speedvale Avenue East and the County's 7667 Speedvale Avenue East are the same building, 1 m apart, under city and rural numbering. OSM already carries 672, and Wellington itself uses city-style numbers (676, 688, 692) for the neighbours, so 7667 reads as a rural number the County never retired. A survey would settle it; nothing here depends on the answer.

Tagging plan

The baseline is the tag mapping Guelph/Address_Import established in 2025, because a continuation that tags differently from the import it continues just creates two conventions in one city. It is reproduced here only where this proposal departs from it or from Toronto's plan. All uploaded elements are nodes; no ways, no relations.

Tag	Value	Note
addr:housenumber	source STREETNO	As Toronto.
addr:street	source FULLNAME	Already in OSM long form ("Cork Street West") on 100% of rows — the suffix-expansion step Toronto needed is a no-op here.
addr:city	Guelph	Delta from Toronto, which omits addr:city. Emitted here to stay consistent with the 2025 import, which wrote it on every node.
addr:province	not written	The one departure from the 2025 baseline, which wrote it as a constant. Omitted per Canadian convention, as in Toronto. This does not leave two conventions standing in one city: the existing tags are removed rather than left in place — see § Mechanical edits.
addr:postcode	enrichment only	Written only when a same-address POI already in OSM carries one. Never invented, never extrapolated.
addr:source	Guelph Open Data	Not a bare source: it sources the address, sits in the addr:* namespace alongside the tags it explains, and survives a later merge into a building polygon without appearing to source the building. The changeset keeps the plain source key — that one describes the edit. Toronto's import wrote a bare source on its nodes and has a scoped follow-up to correct them; Guelph starts correct instead of accruing the same debt. The value is the 2025 import's own string, verbatim — one city should have one attribution value, not two spellings of it — while the key is the corrected one.

Deliberately not emitted: addr:unit (see scope), addr:province (above), addr:ward (the source's 1–6 ward integer is modelled better as an admin polygon), addr:housename, addr:country, addr:full (tested 2026-08-21: Nominatim discards it, so it is a pure duplicate of the structured tags), and any city-specific custom namespace.

Mechanical edits

Two tag cleanups on existing Guelph objects, announced with this proposal but consented separately under the Automated Edits code of conduct. Both are attribute-only: one tag per object, nothing else touched, no geometry, no deletions. Both run neighbourhood by neighbourhood in separately revertable batches, in the same 23-area partition as the import, from the same account.

1. Remove addr:province=Ontario

The 2025 import wrote addr:province as a constant; it is now on roughly 3,699 Guelph objects (against 178 tagged ON). Canadian convention omits province, as does the Toronto import, and the value is fully implied by the enclosing admin boundary. Removed, with no replacement. The ON variants are removed on the same pass rather than harmonised.

2. Split double-encoded unit housenumbers

5,422 objects carry the unit twice: addr:housenumber=714-30 and addr:unit=30 — and in an order that is not the Canada Post one (which writes 30-714), so it is not a postal string either. The fix writes the civic number alone into addr:housenumber and leaves the already-correct addr:unit untouched:

addr:housenumber = 714-30   →   addr:housenumber = 714
addr:unit        = 30           addr:unit        = 30   (unchanged)

Letter suffixes that are the civic number (645A) are not units and are preserved, per the Toronto import's precedent. A further ~17 objects carry the combined form with no addr:unit to confirm the split; those are handled by hand, not mechanically.

The argument, recorded because it was contested. The original importer's position is that the combined form keeps the postal address searchable. Tested against live Nominatim on 2026-08-21, it does not: "72 York Road Unit 5" returns the property with the unit silently ignored, and "5-72 York Road" returns unrelated road segments. Unit-level search is unavailable under every scheme currently available, so it cannot argue for either form — while the combined form additionally breaks plain "714 Willow Road" queries, because then no object carries the bare civic number. The honest summary is that this change costs nothing and buys correct semantics.

Changeset tags for both campaigns

As the import's changeset tags below, except import=yes is replaced by mechanical=yes, the comment names the campaign, and import_plan points at this section.

Changeset tags

Tag	Value
comment	Guelph Open Data address import, run=<run_name>
source	Guelph Open Data
source:license	OGL-Canada-2.0
import	yes
bot	no
created_by	address-importer-friend
import_plan	https://wiki.openstreetmap.org/wiki/Guelph/Address_Import/Continuous
import:client_token	random per-run UUID — used only for server-side idempotent retry after a network failure; looked up before reopening a changeset so a dropped connection never results in two parallel uploads of the same run. As Toronto.

On "continuous" and bot=no: every batch is a separate, operator-triggered run whose candidates are reviewed one at a time in the local web UI before any changeset is opened. Nothing uploads on a timer and nothing uploads unreviewed. The recurring part is the conflation, which is read-only; the upload is a human decision every time. These are therefore imports under the Import Guidelines — import=yes, bot=no — and not automated edits under the Automated Edits code of conduct. If that ever stops being true, this page changes before the behaviour does.

Process

Per cycle, triggered by a change in the source data rather than by a calendar:

1. ontario-address-changes takes a City snapshot and diffs it against the previous one.
2. Fresh OSM extract; full-city conflation — not diff-only, because a maintenance-only mode inherits prior errors invisibly.
3. Candidates land in the review queue by area tile, annotated by the check suite (match_far, city_duplicate, nearby_street_mismatch, missing_sample).
4. Human review in the local web UI. Every candidate is approved or rejected by a named reviewer.
5. Upload, one changeset per tile, at most one changeset per minute.
6. QA findings that are not uploads — street-name disagreements, duplicates, OSM-only addresses — are posted to the forum thread for local mappers, not acted on unilaterally.

Roll-out: one pilot tile first, published on the forum thread with its counts and its changeset, then a one-week hold before the remaining areas. First cycle only; subsequent cycles are ordinary maintenance batches.

Reviewer roster

• Primary maintainer and first-line reviewer: toronto@comentality.com.
• ARandomThumbtack_Import is invited as a reviewer, with a standing veto over anything touching Guelph addresses.
• Local Guelph mappers: contact the address above, or reply on the forum thread.
• No run is uploaded without at least one named reviewer's approval in the UI.

Revert plan

As § Revert plan of the Toronto import. Every upload is a distinct changeset from a dedicated account, with a per-run manifest of (source_id, address, osm_node_id, changeset_id), so any batch can be reverted in isolation without touching neighbouring work.

The import path creates nodes only, so reverting it cannot damage the 2025 import or any organic mapping. The two campaigns in § Mechanical edits do modify existing objects, so they carry the stricter rule: each batch records the prior value and the object version it edited, each is a single-purpose changeset touching exactly one tag, and each is revertable on its own without disturbing the import batches interleaved around it. Any object whose version has moved since the batch was prepared is skipped and re-examined rather than overwritten.

Open questions for the community

1. The two mechanical edits. § Mechanical edits states the intent; the consent is what the feedback window is for. Objections to either campaign — or to the batch size and ordering — belong on thread #135103.
2. addr:city on the 73 Guelph/Eramosa objects. The 2025 import wrote addr:city=Guelph/Eramosa Twp — the City's internal PLACE string — on all 73 (§ The Guelph/Eramosa rows). It is not obviously wrong so much as unexamined: addr:city is the postal community, not the municipality, and the one row of the 75 the City gives a postcode sits in a Guelph FSA. Retagging 73 objects would be a third mechanical edit needing its own consent, so it is raised here as a question, not proposed. What should the value be — or should it be left alone?
3. ;-lists and addr:flats. Roughly 800 objects carry ;-separated housenumbers, and one carries unit ranges in addr:unit where addr:flats belongs. Both want door positions rather than a mechanical rule, so the plan is a MapRoulette challenge rather than a batch — is that wanted?
4. Cadence and quiet. How often should a maintenance batch be announced on the forum thread: every batch, or a periodic summary?

References

• Guelph/Address_Import — the 2025 import by ARandomThumbtack_Import; the record of the work this builds on.
• Toronto/Import/AddressPoints — the long-form proposal for the same tooling: conflation, checks, review UI, audit log and revert plan in full.
• Import/Guidelines, Import/Catalogue, Automated Edits code of conduct.
• City of Guelph address points — source dataset.