Guelph/Address Import/Continuous

From OpenStreetMap Wiki
Jump to navigation Jump to search

Template:Map of imports

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: In progress. The gap-fill, campaign 1 and campaign 2 were announced on 2026-08-28 and their 14-day objection window closed on 2026-09-10 with no objections.
    • Campaigns 2 and 3 are finished — 5,521 and 447 objects, 59 changesets between them, all from the skfd imports account except the very first, which went from the maintainer's personal account by mistake and is disclosed on the thread.
    • Campaigns 4 and 5 are built and announced, and have uploaded nothing yet — 325 objects in 22 batches, going up the weekend of 2026-09-19/20.
    • Campaign 1 is built and held — 44,763 objects in 105 batches, prepared 2026-09-17 and waiting on the corrected consent described in § Mechanical edits, 1. An earlier revision of this bullet said it had not been built, which that section already contradicted three screens further down.
    • The import itself has not run.
  • Announced on short notice, 2026-09-18: campaigns 4 and 5 — post #21, uploading the weekend of 2026-09-19/20. The same call as below, for the same reasons, and it is the third time it has been made: a reader entitled to think once was reasonable is entitled to think three times is a habit, and saying so is the point of this bullet. Both are attribute-only on a set enumerated object by object, with the prior value and the object version recorded for every one. Reverted on request. The posted notice is shorter than the page: it does not carry the 81-of-635 scope, the round-trip gate or this timing statement, so this page is where those live.
  • Announced on short notice, 2026-09-16: the reversal in § Unit-level addresses and campaign 3. These are announced, not consented — they are proceeding without waiting out a fresh 14-day window, which is a deliberate choice by the maintainer and is recorded here rather than glossed. The reasoning is that both are tagging changes on a single well-defined set, fully and mechanically reversible, with the prior value recorded per object; neither deletes anything, moves any geometry, or touches any object outside the sets described below. If anyone objects, the affected batches are reverted on request — no argument first — and ARandomThumbtack's standing veto over anything touching Guelph addresses is unaffected by the pace. A reader who thinks this was the wrong call should say so on thread #135103; that judgement is theirs to make and the record is here to make it on.
  • Last revised: 2026-09-18
  • 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, five one-off mechanical tag cleanups on Guelph's existing address objects: removing addr:province=Ontario, splitting the unit back out of double-encoded housenumbers, moving unit lists from addr:unit to addr:flats, removing addr:interpolation from the shapes it cannot describe, and normalising the addr:flats values the third campaign deliberately moved verbatim. All five are described in § Mechanical edits; the last two were found while running the middle one. 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 Uploaded, by shape — [units] policy = "per-door-or-collapse". This reverses what this page said until 2026-09-16, which was that units would not be uploaded at all; see § Unit-level addresses for the reasoning and the numbers. Units that are separate front doors become one node each with addr:unit; units stacked in a building collapse to one civic node listing them in addr:flats. 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 five campaigns in § Mechanical edits are the sole exception, they are announced and consented separately from the import, and they touch only the tags named there — nothing else on the object, and no geometry.
  • No polygons, no geometry editing.
  • No addr:interpolation cleanup. Withdrawn 2026-09-18 — see the revision note below, and § Mechanical edits, 4.

Revised 2026-09-18. This list also read "no addr:interpolation cleanup" — published 2026-08-27, struck above. Campaign 4 is exactly that cleanup, so the promise is withdrawn rather than reinterpreted. What it was protecting still stands, now as the campaign's own scope rule: the 405 legitimate two-node interpolation ways and the 149 multi-node ones are not touched, no geometry is edited and nothing is deleted. What changes is that a key is removed from 78 building outlines and 3 nodes — shapes the tag cannot describe at all. The non-goal was written when the plan was to leave the key alone entirely; running campaign 3 showed what it was actually being used for, and leaving it would have left one mistake standing under a second key.

Revised 2026-09-16. Until that date this list also read "no unit-level addresses uploaded". It no longer does. Nothing else in the non-goals changed, and the reversal is set out in full, with its counts, in § Unit-level addresses — it is called out here rather than quietly deleted because a non-goal that has been published is a promise, and a reader who remembers the old one is owed the change.

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:unit source UNIT_NO New 2026-09-16. On per-door nodes only — a node tagged addr:unit asserts that it is that unit, which is true of a front door and false of a building. Never written alongside addr:flats. See § Unit-level addresses.
addr:flats the unit list, as ranges New 2026-09-16. On collapsed nodes only — addr:flats means containment: this node serves these units. Semicolon-separated ranges broken wherever the numbering skips, e.g. 101-110;201-212;301-312. See § Unit-level addresses.
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: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.

Unit-level addresses

This section reverses a published non-goal. Until 2026-09-16 this page said units would not be uploaded and source rows would collapse to one candidate per civic address. They now upload, and the decision is set out here in full — including the numbers it rests on — so that it can be argued with rather than discovered in a changeset.

What changed and why

The old plan treated "unit" as one thing to be either kept or dropped. The City's data does not: 13,162 of its rows carry a unit, and they describe two different situations. A row for a townhouse door and a row for suite 906 of a tower are not the same object at a coarser resolution — they are different objects. Collapsing both lost the doors; uploading both as nodes would have scattered 142 nodes through one tower.

So the policy is now per-door-or-collapse:

  • Units that are separate front doors become one node each, carrying addr:unit.
  • Units that are stacked inside a building collapse to one civic node, carrying addr:flats.

This reads the City's own geometry rather than overriding it, and it means conflation is told about units instead of comparing bare housenumbers and guessing. It is Guelph-specific: Toronto and Hamilton keep the previous collapse-to-civic behaviour unchanged.

What decides which

The unit numbering, not the geometry. Two earlier attempts to decide this by spacing alone were both wrong: 93 Arthur Street South runs units 101–1411 over prefixes 1–14 — a fourteen-storey building — and a spacing test called it 193 front doors within 66 m.

The rule: strip the last two digits from each unit. If what remains takes two or more values, the scheme is floor- or building-coded and the units are stacked, so the group collapses. Purely sequential numbering (1…214) means doors. Letter-prefixed codes (D101) are building letters and count as coded.

Geometry is the guard, not the decision. A sequential group whose points sit less than 2 m apart has no distinct per-unit location and collapses regardless; between 2 m and 4.5 m — under the width of the narrowest real townhouse — it is flagged for a human rather than assumed.

Run over all 514 stacked groups in the source:

Outcome Groups Units Why
Collapse 87 5,093 Floor- or building-coded suites
Collapse 22 575 Sequential, but under 2 m apart — no distinct location
Per-door nodes 240 6,111 Sequential, door-width spacing
Review, emitted collapsed 58 1,381 Sequential but tighter than 4.5 m
No unit rows 107 0 Civic duplicates; not a unit question at all

So 349 of the 407 unit-bearing groups decide themselves and 58 want eyes — about one in seven. The review cases are emitted collapsed rather than held back, because collapsing is defensible either way and it puts one node in front of the reviewer instead of 140 to reject. 252 Stone Road West is the honest example: a mall whose 140 "units" are storefronts, and whether a storefront is a front door is not a judgement any rule should be making silently.

addr:flats, and its limits

Collapsed nodes list their units as semicolon-separated ranges, broken wherever the numbering skips. A single range would be a lie: Guelph's tower units are floor-coded, so 19 Woodlawn Road East runs 101 to 915 while holding 142 units, and only 2 of 46 all-numeric towers are contiguous. 23 Woodlawn Road East, 103 units, comes out as 

101-110;201-212;301-312;401-412;501-512;601-612;701-705;707-712;801-812;901-909;911

where 701-705;707-712 and 901-909;911 are real gaps in the building, not tidying.

Measured across all 167 collapsed groups the median value is 23 characters. Three do not fit OSM's 255-character limit — 85 Mullin Drive (110 units as 1A;1B;2A;2B…, 421 characters), 176 Janefield Avenue (303) and 15 Carere Crescent (261). Nothing compresses a suffixed or stepped sequence, so those three have their listing dropped rather than truncated — a truncated list would assert that the building ends where the cut landed — and the candidate is flagged so the loss is visible rather than silent.

The overflow turned out to be a misclassification detector, 2026-09-17. Measured, those three are not buildings: 15 Carere Crescent is 66 units spread over 103 m × 114 m, 85 Mullin Drive 110 units over 186 m × 119 m, 176 Janefield Avenue 76 units over 205 m × 175 m. A tower is about 40 m square. These are complexes — 15 Carere is 32 separate townhouse blocks, which OSM already maps individually — so collapsing each to a single civic node is wrong, and the listing overflows precisely because the group is too spread out to be one building. The classifier decides on the unit numbering and never asks how far apart the units are once it has called the scheme coded. The fix is a footprint guard on the collapse branch; until it lands these three are flagged, and a reviewer should route them to per-door nodes by hand. Raising the limit or truncating would bury the real fault.

addr:flats is rare in Ontario and this is close to a first at scale: 58 objects province-wide against 29,312 carrying addr:unit (counted 2026-09-15). That is precisely why it is raised here instead of being slipped in. The key is chosen because it means containment — this node serves these units — where addr:unit means identity. They are not two spellings of one idea, and no node gets both.

Known limits, stated up front

  • Unit-level search does not work under any scheme. Tested against live Nominatim on 2026-08-21: addr:unit and addr:full are both discarded. This buys correct data, not findability, and that cost is accepted rather than mitigated.
  • The maintenance path for units is deliberately not built. A new unit at an already-collapsed building needs addr:flats modified on an existing node, and this import only ever creates. Until that is closed, unit-bearing runs go through the tile path only, never the recurring maintenance job, and a new unit at a collapsed building is routed to a QA finding instead of an upload. A retired unit has the mirror problem and likewise shrinks nothing.
  • Ordering. The split in § Mechanical edits runs before any of this. Before it, OSM carries a door's address as 714-30, which a door candidate of (714, unit 30) does not match — so the door would read as missing and a second node would be proposed beside the badly-encoded one. With 5,568 hyphenated objects against 6,111 door candidates, the wrong order mass-produces duplicates. The same holds for the listing retag (§ Mechanical edits, 3): a collapsed candidate with no unit does not match a building whose addr:unit is a list, and 125 collapsed buildings plus 51 door groups would be proposed beside buildings that already list their units. The conflation is also being taught to read both forms, because an extract always lags an edit — but reading both is the safety net, not the plan.

Mechanical edits

Five tag cleanups on existing Guelph objects, each announced separately from the import under the Automated Edits code of conduct. 1 and 2 were consented through a 14-day window (announced 2026-08-28, closed 2026-09-10 with no objections). 3, 4 and 5 were announced without one — 3 on 2026-09-16, 4 and 5 on 2026-09-18 — see § Status for why, and for the standing offer to revert any of them on request. All are attribute-only: one tag per object, nothing else touched, no geometry, no deletions. The third moves one value between two keys; the fifth rewrites one value in place without changing what it says. All run neighbourhood by neighbourhood in separately revertable batches, in the same 23-area partition as the import, from the same account.

4 and 5 share one batch set, and are one announcement and one revert, because they land on the same buildings: 74 of the 81 objects in campaign 4 also carry addr:flats, and 48 objects take both edits. Run separately, the second would have conflicted against the first on object version, and would have announced twice what a reader sees as one cleanup of the same apartment buildings. Together they are 325 objects in 22 batches — 244 re-rendered only, 33 de-interpolated only, 48 both — with 146 further objects skipped rather than uploaded as no-ops, because they were already correct.

1. Remove addr:province=Ontario

The 2025 import wrote addr:province as a constant; it is now on 44,796 Guelph objects — 44,155 Ontario, 607 ON and one On, re-measured against Overpass 2026-09-17. Against 47,050 objects in the city carrying addr:housenumber, that is very nearly every address object in Guelph. 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, in their own batches at the end of the run so they can be held back independently.

Correction, 2026-09-17. This section, and post #14 that sought consent for it, both said ~3,699 objects. That was wrong by a factor of twelve, and it is recorded here rather than quietly overwritten. The figure was a sample count published as a census: the entry-state probe (onboarding/entry-state-2026-08-15.json) read 4,244 Guelph elements and found addr:province on 3,878 of them, and the 3,699/178 split quoted above was that sample's breakdown. Nothing had been measured city-wide. The edit's definition is unchanged and still stands on the same reasoning; only its size was misstated. The 2026-09-10 objection window is not being treated as covering the corrected scope. The correction is drafted but not yet posted as of 2026-09-18 — it is written up in the repository as PROVINCE_CORRECTION_POST.md and belongs on the thread. Nothing uploads until it is up and the community has answered whether a fresh window is wanted. An earlier revision of this page said the correction was already on the thread; it was not, and this sentence is the fix.

Prepared, 2026-09-17: 44,763 objects in 105 batches, one per area with large areas split at 600. 33 objects are held back for hand review — 29 carry addr:province with no addr:housenumber (boundaries and place=* nodes rather than addresses) and 4 are relations, which this tooling never batches. Every object is recorded with the version it was prepared against and its prior value in manifest.csv.

2. Split double-encoded unit housenumbers

5,521 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. (Re-measured 2026-09-16 against live OSM: 5,568 objects carry a hyphen in addr:housenumber, of which 5,521 split mechanically and 47 do not. The announcement said 5,422; that was August's count and the figure has drifted up since.) Done, 2026-09-16: 5,521 objects in 36 changesets, one per area, the pilot being changeset 189086416 (69 objects, June Avenue). Every edited object is recorded with the version it was prepared against and its prior housenumber in manifest.csv, and each batch with its changeset in uploads.csv. 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. Of the 47 left out: 17 carry the combined form with no addr:unit to confirm the split — the ones this page always said would be done by hand — 27 are ;-separated housenumber lists that belong to the MapRoulette question in § Open questions rather than to this campaign, and 3 carry an addr:unit matching neither side of the hyphen (130-BLD D, 10-6/7). None were touched by this campaign.

Amendment, 2026-09-17. 32 of those leftovers were then done mechanically, after a second witness was consulted: the City's own address roster. This page previously said the ~17 uncorroborated ones would be "handled by hand", and that is recorded here rather than quietly overwritten. Twelve ways on Bond Court tagged 37-1…37-12 carry no addr:unit at all, but the City lists exactly units 1–12 at number 37; eighteen ;-lists turned out to be one civic number with unit suffixes, every suffix matching the roster. The edit is the same edit — only the evidence changed, from the object's own tags to the published roster. 12 objects remain genuinely manual, and 3 are real ranges left alone.

These batches are prepared as .osm files carrying the live version of every object and uploaded from JOSM, so an object edited since the batch was prepared raises a conflict rather than being overwritten — the § Revert plan promise, enforced by the upload rather than by care. Because JOSM does the uploading, created_by on these changesets reads JOSM rather than the tool named in § Changeset tags; JOSM stamps its own and nothing else survives.

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.

3. Move unit lists from addr:unit to addr:flats

Done, 2026-09-17: 447 objects moved, in 23 changesets. 453 Guelph objects carry a list of units in addr:unit — addr:unit=101-116;201-215;301-314;… on one building way, the whole tower on one object. Counted 2026-09-15 against a fresh extract. The open questions on this page used to say "one" carried unit ranges where addr:flats belongs; that was a count by eye and it was wrong by two orders of magnitude. They cover 176 of the City's 409 unit-bearing civic addresses, and 167 of the 176 listings match the City's unit roster exactly — they were mapped from the same data, and mapped carefully.

addr:unit means identity — this address is unit 30 — and its wiki page allows several values only for one address that spans adjacent units. A building that contains units 101–116 is what addr:flats is for: "the range of unit numbers within a larger building or complex", on the building way or its entrance, in exactly this 3-7;10;14-18 format. Guelph currently says "door" with addr:unit on 5,863 objects and "building" with the same key on 453, and nothing but the shape of the value tells them apart. The fix moves the key and touches nothing else: 

addr:unit  = 101-116;201-215;…   →   addr:flats = 101-116;201-215;…
                                       (addr:unit removed; every other tag and the geometry untouched)

A single-valued addr:unit is a door and is not touched.

Two limits found while running it, both recorded because they qualify the result. First, the premise fails on a POI. addr:unit on a shop or cafe means this business is in that unit — identity — so rewriting it to addr:flats claims the business contains a unit. One went up before this was noticed (Centurion Coffee, fixed by hand); every remaining batch was then swept and five more pulled. The discriminator is building, not the POI tag: a nursing home tagged amenity=social_facility is the structure and really does contain its units, while a bare node with shop=shoes is a tenant of one. Second, 15 of the 447 are commercial — Melran Mall now reads addr:flats=100-140. The key is defined as "the range of unit numbers", with flats as the example rather than the restriction, and no alternative key exists; but these counts are storefronts and must not be read as dwellings. The one object already carrying addr:flats is left alone. Values move verbatim — not re-compressed, not reconciled against the City's list — so the edit is exactly reversible and asserts nothing the original mapper did not.

Why a campaign rather than a note. § Unit-level addresses has the import writing addr:flats for collapsed buildings; without this edit Guelph would carry the same fact under two keys, split about evenly, indefinitely. And conflation has to be able to tell a door from a building by key: with both meanings on addr:unit it can only guess from the value, and the first version of that guess froze 158 buildings for the wrong reason. addr:flats being rare in Ontario is the reason this is asked rather than done.

4. Remove addr:interpolation where it cannot mean anything

Announced 2026-09-18; uploading 2026-09-19/20. 81 objects lose the key and 554 keep it. This campaign withdraws a non-goal this page published on 2026-08-27; § Non-goals records that rather than deleting it.

addr:interpolation describes a way drawn between two address nodes: the numbers run from the housenumber at one end to the housenumber at the other. It cannot mean anything on a shape with no two ends. Guelph carries it on 635 objects, surveyed against Overpass on 2026-09-17:

Shape Count This campaign
2-node open way 405 Not touched. Real interpolation, correctly tagged.
Open way, 3+ nodes 149 Not touched. Legal in principle, and wants a different question asked of it — do both ends carry addr:housenumber? — which is not this edit.
Closed way 78 Removed. A building outline has no two ends, and its corners are geometry that will never carry a housenumber.
Node 3 Removed. A single node has nothing to interpolate between.

Which 554 are left alone matters more than the 81: "removing addr:interpolation from Guelph" reads as a city-wide sweep of a key that is mostly tagged correctly, and it is not one. Every refusal is recorded with its reason in the campaign's review.csv.

It is the same mistake campaign 3 fixed under a different key. Whoever tagged a building addr:interpolation=all was reaching for "this building contains a range of addresses" — which is what addr:flats means and what addr:interpolation does not. 74 of the 81 already received addr:flats in campaign 3, so the right key is in place and this removes the wrong one. It is also what JOSM has been reporting on those buildings as "End node without housenumber in address interpolation"; the warning is pre-existing, it is what turned the campaign up, and it will otherwise nag every mapper who opens one of them.

5. Normalise addr:flats formatting

Announced 2026-09-18; uploading 2026-09-19/20. 292 of the 464 objects carrying addr:flats are re-rendered, and not one of them changes which units it names. Campaign 3 moved 447 unit lists verbatim, on purpose — that promise is what made it trivially reversible — and this is the tidy-up afterwards. The 172 values already in the right form are left byte-for-byte alone.

Four defects, at least one of which is present on each of the 292:

Defect Objects Live Becomes
Enumeration that should collapse 235 1;10;11;12;13;14;15;2;3;4;5;6;7;8;9 (803 Gordon Street) 1-15
Trailing ; 49 101-113;201-214;301-314;401-414; no trailing separator
Sorted as text, not numerically 14 1001-1008;1101-1108;101-106;… (358 Waterloo Avenue) floors in numeric order, thousands last
Spaces around ; 2 201-209; 301-309; 401-409; (55 Yarmouth Street) no spaces

(The counts overlap — a value can carry more than one defect.)

The rendering is not invented for this campaign. It is compress_flats in the import's own code — the function every collapsed building the import uploads already goes through. The only new code is a parser to read an existing value back, which is where the risk is. So every value is gated on a round trip: parse it, render it, parse the rendering, and require the two sets of units to be identical. If normalising ever changed which units a building claims, that would be data loss dressed as tidying. Anything failing the gate is left alone for a by-hand list. 464 parsed, 464 passed, 0 refused.

What the parser is careful about, each with its own test: 101A is one unit and never joins a range, so 511 Edinburgh Road South goes 101;101A;102;201;202 → 101-102;101A;201-202; D101-D112;D201-D212 are two building-D runs and never merge across letters; LL01 is a real lower-level floor and keeps its zero, which needed a fix in the import itself (unit_pad, threading a per-prefix width through compress_flats); and 176 Janefield Avenue is a row of blocks numbered in steps of two, so 224;234 stays 224;234 rather than becoming 224-234 and claiming nine units that do not exist.

The 255-character tag limit is not reached. Guelph's longest addr:flats is 154 characters; after normalising the longest is 153. No value grows — 163 get shorter, 129 stay the same length — and a test asserts both bounds across all 464. Three known listings would overflow, but they are refused source-side and were never written to OSM, and they are exactly the shapes compress_flats cannot shorten anyway.

Changeset tags for all five 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 five 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, and each is revertable on its own without disturbing the import batches interleaved around it. A batch touches exactly one tag, with one deliberate exception — campaigns 4 and 5 share a batch set and so touch two, because 48 objects take both edits and splitting them would mean two changesets and two reverts for what is one cleanup of one building. 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 mechanical edits — and which of them are actually settled. Campaigns 1 and 2 were announced on 2026-08-28 with a 14-day objection window that closed on 2026-09-10 with no objections, so they are consented and running. Campaign 3 and the reversal in § Unit-level addresses are announced on 2026-09-16 and proceeding without a window, and campaigns 4 and 5 the same way on 2026-09-18 — the maintainer's judgement that all of them are reversible tagging changes not worth a fortnight's pause, stated openly in § Status rather than left to be noticed. Three short-notice calls in three days is a pattern rather than an exception, which is the honest way to describe it. That judgement is exactly the sort of thing this section exists to collect disagreement about: if it was wrong, saying so on thread #135103 gets the batches reverted, not defended.
  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 fourth 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 in addr:housenumber. Roughly 800 objects carry ;-separated housenumbers — 137-B;139-A;137-A;137 on one way. Unlike the unit lists, these want door positions rather than a key change, so no mechanical rule fits them and the plan is a MapRoulette challenge rather than a batch — is that wanted? (Revised 2026-09-16: this question previously also said "one" object carried unit ranges in addr:unit where addr:flats belongs. That was a count by eye and it was wrong — there are 453. They are now campaign 3 in § Mechanical edits, which is the honest place for them.)
  4. Cadence and quiet. How often should a maintenance batch be announced on the forum thread: every batch, or a periodic summary?

References

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Guelph/Address_Import/Continuous&oldid=3081129"