Toronto Address Interpolation Elimination Maproullete

Communities Canada
,
1

The Toronto address import is done — the City’s address points are now in OSM. That makes the old addr:interpolation lines obsolete: roughly 69,000 of them across the city, mostly from the StatCan/CanVec imports years ago. They were a good estimate when we had nothing better. Now we have the real thing, and the lines need to go.

So — a mapping party.

How it works

One MapRoulette task per interpolation line. Each task shows the house numbers the City actually has for that block, and asks you to:

  1. Align buildings and address points to the Bing imagery layer.
  2. Verify every house number is present — as an individual node, or as an address on a building if it’s the only one. Split comma/semicolon-separated addresses into individual nodes. Use the Toronto Address Layer if something looks misaligned or missing.
  3. Delete the interpolation line — select the endpoint nodes and delete them, the editor takes the way with them. If you delete the way directly, the nodes are left over.

Challenges are marked expert difficulty / local knowledge. If you know the area, you’ll be faster and better at judging the weird cases.

Pilot: southwest Etobicoke

Starting small to shake out problems before going city-wide. Four challenges along the lakeshore, one per neighbourhood:

  • Long Branch — 263 tasks
  • New Toronto — 186 tasks
  • Alderwood — 443 tasks
  • Mimico-Queensway — 323 tasks

Project: MapRoulette

If the pilot goes well, I’ll roll out one challenge per neighbourhood for the whole city — every neighbourhood that has interpolation lines gets its own. Adopt yours.

Lines where the City has no usable data are held back for manual review, they don’t become tasks. Tooling is here if you want to look under the hood: https://github.com/skfd/against-interpolation

Feedback

Post problems and suggestions in this thread — task wording, bad matches, lines that should stay, anything. The task instructions link back here.

All 158 neighbourhoods (planned coverage)

Agincourt North, Agincourt South-Malvern West, Alderwood, Annex, Avondale, Banbury-Don Mills, Bathurst Manor, Bay-Cloverhill, Bayview Village, Bayview Woods-Steeles, Bedford Park-Nortown, Beechborough-Greenbrook, Bendale South, Bendale-Glen Andrew, Birchcliffe-Cliffside, Black Creek, Blake-Jones, Briar Hill-Belgravia, Bridle Path-Sunnybrook-York Mills, Broadview North, Brookhaven-Amesbury, Cabbagetown-South St.James Town, Caledonia-Fairbank, Casa Loma, Centennial Scarborough, Church-Wellesley, Clairlea-Birchmount, Clanton Park, Cliffcrest, Corso Italia-Davenport, Danforth, Danforth East York, Don Valley Village, Dorset Park, Dovercourt Village, Downsview, Downtown Yonge East, Dufferin Grove, East End-Danforth, East L’Amoreaux, East Willowdale, Edenbridge-Humber Valley, Eglinton East, Elms-Old Rexdale, Englemount-Lawrence, Eringate-Centennial-West Deane, Etobicoke City Centre, Etobicoke West Mall, Fenside-Parkwoods, Flemingdon Park, Forest Hill North, Forest Hill South, Fort York-Liberty Village, Glenfield-Jane Heights, Golfdale-Cedarbrae-Woburn, Greenwood-Coxwell, Guildwood, Harbourfront-CityPlace, Henry Farm, High Park North, High Park-Swansea, Highland Creek, Hillcrest Village, Humber Bay Shores, Humber Heights-Westmount, Humber Summit, Humbermede, Humewood-Cedarvale, Ionview, Islington, Junction Area, Junction-Wallace Emerson, Keelesdale-Eglinton West, Kennedy Park, Kensington-Chinatown, Kingsview Village-The Westway, Kingsway South, L’Amoreaux West, Lambton Baby Point, Lansing-Westgate, Lawrence Park North, Lawrence Park South, Leaside-Bennington, Little Portugal, Long Branch, Malvern East, Malvern West, Maple Leaf, Markland Wood, Milliken, Mimico-Queensway, Morningside, Morningside Heights, Moss Park, Mount Dennis, Mount Olive-Silverstone-Jamestown, Mount Pleasant East, New Toronto, Newtonbrook East, Newtonbrook West, North Riverdale, North St.James Town, North Toronto, O’Connor-Parkview, Oakdale-Beverley Heights, Oakridge, Oakwood Village, Old East York, Palmerston-Little Italy, Parkwoods-O’Connor Hills, Pelmo Park-Humberlea, Playter Estates-Danforth, Pleasant View, Princess-Rosethorn, Regent Park, Rexdale-Kipling, Rockcliffe-Smythe, Roncesvalles, Rosedale-Moore Park, Runnymede-Bloor West Village, Rustic, Scarborough Village, South Eglinton-Davisville, South Parkdale, South Riverdale, St Lawrence-East Bayfront-The Islands, St.Andrew-Windfields, Steeles, Stonegate-Queensway, Tam O’Shanter-Sullivan, Taylor-Massey, The Beaches, Thistletown-Beaumond Heights, Thorncliffe Park, Trinity-Bellwoods, University, Victoria Village, Wellington Place, West Hill, West Humber-Clairville, West Queen West, West Rouge, Westminster-Branson, Weston, Weston-Pelham Park, Wexford/Maryvale, Willowdale West, Willowridge-Martingrove-Richview, Woburn North, Woodbine Corridor, Woodbine-Lumsden, Wychwood, Yonge-Bay Corridor, Yonge-Doris, Yonge-Eglinton, Yonge-St.Clair, York University Heights, Yorkdale-Glen Park

cc: @Nate_Wessel @Jarek

1 Like
Address import for Toronto
2

I would add a note to avoid alignment changes that are less than 2 m or so, unless the building has clearly been rebuilt or expanded, or unless there’s intersections with other buildings.

Currently the various aerial imageries have an offset of about a metre, and the imported buildings seem to match Esri best. Realigning everything to Bing will be a lot of work for rather little benefit. I still don’t actually know which alignment is most accurate, and I’m not sure how we would find out.

E.g. Hillside Avenue, Mimico:

City of Toronto imagery:

image
image1183×823 370 KB

Esri:

image
image1183×824 297 KB

Bing:

image
image1178×818 279 KB

1 Like
3

I tested which sat layer is best when I walk around with gps, and Bing is dead on each time. It’s true that most buildings are aligned based on some import, but it’s also is an incorrect position.

It’s maybe ok for streets that go West-East, but it’s a problem when street Is North-South and the mis-alignment between address nodes and buildings is very clear and can become a building-address matching headache.

Bing, City Data address nodes, my GPS surveying in different suburbs – all match positions. Imported buildings are all drifted to South as you illustrate.

This is why I think why mapping party might as well include truing building positions. Interpolation removal is just a occasion, but this mapping party is more about reviewing the data that has not been touched for some time.

This is a pilot, testing how challenge feels, let’s fix wordings for sure though!

4

Is this a survey-grade GPS with sub-meter resolution, or an ordinary consumer GPS with 3-meter-at-best resolution?

5

of course it’s just walking with a phone, but I invite anyone who owns Trimble stick to prove me wrong…

6

So, I don’t have a pro-grade GPS device, but I do have a copy of a cadastral survey of my neighbour’s house, and it tells me that our fence is on the property line [1]. That fence goes east-west [2]. When I compare the City’s property boundaries WGS84 geojson with aerial imagery using JOSM, City’s imagery shows the fence about 40-50 cm to north of where the geojson shows the property boundary to be, Esri seems to be the same except refusing to load at really high zooms, and Bing shows the fence about 1.4 m to north of where the geojson shows it. Sorry no screenshot because I don’t want to doxx myself too much.

Of course it’s possible that the city’s property boundaries aren’t extremely accurate…

Another example, not from my street, from Central Street in Mimico. Black lines are City’s property boundaries. Buildings were shifted by Nate to Esri’s 2019 alignment.

City’s imagery:

image
image948×825 286 KB

Bing imagery:

image
image943×819 201 KB

To my eyes, the fences, hedges, and edges of driveways seem closer to City’s imagery than to Bing’s, and buildings seen on City imagery better fit within the boundaries. Of course it’s possible that they were built offset from the theoretical property boundaries…

But overall, I don’t think that mass realigning imported buildings (which BTW are imported from a dataset based on City data), to any imagery, is a good use of time at this point. Not only because they might change next year.

  1. in many cases, a fence isn’t actually at the property line, but in this case, according to the survey it is ↩︎

  2. well, the usual Toronto WSW-ENE ↩︎

1 Like
7

Ok, I removed the re-alignment point. Could you please review if there is anything else in text I should update? Also Do you think Hard, and Local Knowledge are correct settings for it?

Strategic question – isn’t it a lot of manual work, should we actually do some deletions automatically?

8

I think it would be better to do the deletions manually rather than rely on another automatic process because I noticed some areas affected by the import now have three addresses per address point - interpolation, address on the building, and address node. So this will be a good opportunity to clean up after any imperfections left by the automatic import.

It was a few days ago that I noticed this. I don’t remember where, but I can find it again if you want me to show you for reference.

Also, not that it matters for this effort, but I have found the City’s aerial imagery to be the most up to date compared to Bing, Esri, and the Province’s, by checking what each layer had for the Rogers Stadium. The City’s imagery shows it furthest along in construction.

2 Likes
9

Well, I took care of a few dozen for you in the “Alderwood” area:

Hopefully that took a little bite out of it. :)

2 Likes
10

fantastic work! can you please share some takeaways from that about map before you started, satellite imagery quality etc?

1 Like
11

Hmmm… well, I skimmed through the Toronto Address Import thread (and this one).

Q1. Do you think it would be a good idea to do the:

If these address nodes get merged with houses, then you just get:

  • source=City of Toronto Open Data

But if it was tagged with:

  • source:addr=City of Toronto Open Data

perhaps it might become a little easier to understand where these addr:housenumber and addr:streets came from… just in case of errors (or more extra cleanup was needed in the future).

Q2. For satellite footage, I used:

  • Bing
  • Esri World Imagery (Clarity) Beta

The Esri stuff was pretty high quality, and it was able to “see through” some of the trees and get better views.

If you think other city footage might work better… knowing the exact name it shows up with in ID would be a huge help.

In JOSM, I see:

  • Toronto Orthorectified Imagery - Most current year

… along with about 4+ overlapping years of “Geospatial Ontario Imagery Data Services” stuff.

Mapping Note #1: For the most part, I noticed the same odd Bing alignment issues you did.

Seems like many of the “horizontal streets” were okay, but many of the “vertical ones” were odd.

(In JOSM, I just roughly applied an offset to line up most of the buildings by eye.)

There were already some smaller buildings in between (like sheds and garages) that were drawn over the years using some sort of different satellite footage… so if I saw a garage WAY off, I “realigned” it to the house. (So instead of having 90% buildings aligned and 10% definitely off… at least they’ll all be “equivalent”.)

Mapping Note #2: In that little section of Alderwood, the address nodes were fantastic. 0 issues.

There was only 1 duplex building where I saw 2 address nodes above it, and I was able to “karate chop” it in half in 1 second. :)

Mapping Note #3: For the most part, I just followed my step-by-step “How to Conflate Addresses” tutorial.

And because someone already laid the groundwork with all these:

  • building=detached

it made it so much easier to:

  • Select all the houses in an area.
  • Select the address nodes.
  • … and then smush them all together, a few blocks at a time. :)

So I verified and cleared out a few blocks, or a nice 2x2 grid of streets—merged all addresses in that little “square”—then moved on to the next piece.

1 Like
12

In general, I strongly recommend that plain source be added on changesets only. Most of the time, it’s easy to follow the object history and check the changeset source so source:* isn’t even needed either.

1 Like
13

About 1100 more houses done:

And wow, now that these interpolations are out of the way, there’s so much less clutter on the map. Trying to drop little fire hydrants or do some sidewalk details are going to be so much easier now. :slight_smile:

Mapping Oddities #1: Flipped addr:interpolation

I caught 2 old addr:interpolation that were accidentally the wrong way! Untouched since 2010.

Instead of numbers like:

  • 36->38

it accidentally went:

  • 38->36

(So those 4 houses on the end of a cul-de-sac that had wrongly flipped addresses—all gone and cleaned up now! You’re welcome! :slight_smile: )

Mapping Oddities #2: sidewalk_orientation

I caught quite a few of these on fire hydrants:

It looks like this only exists in the Toronto area… and was added by some users back in 2015–2017.

As I was spotting them and adjusting their locations, I also upgraded the hydrants to the correct:

Almost all of these were:

  • fire_hydrant:position=green

sources + TagInfo + Disentangling Messiness

But in this specific case… Poof, address nodes disappear. No history to trace back and see links back to this 2026 import.

For example, see:

So there’s absolutely no traces of original address node at all now, linking back to Changeset #182904656 (the 2026 import).

With a clear source or source:addr name attached, this allows you to use the Wiki/Forums or TagInfo to stumble upon the Import page using alternate methods too. For example, using:

You can use this to catch some really “odd”/“old”/“extremely-low-used” values, then use Overpass Turbo to take a quick look at that location and see if you could fix it up. For example, I just used:

to spot these weird addr:interpolation values in Ontario:

  • 17 = yes
  • 1 = even; odd

Bing bang boom, you could hop right to those random spots and fix those up:

I’ve used this method in TagInfo quite a few times too… doing cleanup and normalization in those rare typos or “few dozen” usages.

Or it’s fun to roughly track:

Also, like @skfd noted:

there was a few accidental floating CanVec 6.0 - NRCan address nodes, where someone deleted the addr:interpolation line between, but accidentally forgot the address on both ends.

Trying to disentangle this is so much easier when you have source-type tags lingering there, so you know which thing is potentially more “up-to-date” or “trustworthy”.

For example, there was 1 or 2 spots where someone dragged the CanVec address node directly over a house. I saw 2 or 3 mismatching addr:housenumber nodes floating over a house, so I was able to quickly use this latest one to figure out which of the nodes/streets were “correct”:

  • 1 had source=CanVec 6.0 - NRCan
  • 1 had source=City of Toronto Open Data

(And yep, CanVec’s housenumber was “off by 2”, while this 2026 import was bang on.)

No need to mess with View > History or try to go back 1 or 2+ versions to try to figure out what’s going on.

Side Note: Also, a similar trick can be done with JOSM’s Search. I was able to mass search:

  • source=City of Toronto Open Data

and have about 500 correct address nodes per chunk selected and prepped for Conflation. As I went block-by-block, I merged them right into houses cleanly. (Then did a final verification with latest Toronto Orthography, then purged those old addr:interpolations!) :slight_smile:

If these were blank nodes… ugh, it would’ve potentially been messier during conflicts.

1 Like
14

oh nice, I need to jump on that train, spend more time in JOSM.

I’m still looking into this, but so far it’s not easy for me to do super cleanly. But i’m trying!

Thank you for supporting the initiative, I think the use of that JOSM tool and the energy is the key here!

Yeah ESRI has never sat images, but when I survey in the streets from my phone Bing imagery is always dead on with where I’m standing, so I have a huge confidence in it’s alignment even during tele-mapping. Why canvec has a drift that matches ESRI’s and Toronto data matches Bing imagery is a huge mystery to me still.

1 Like
15

That was one of the random “annoyances” I mentioned in hallway discussions during the SOTM US.

Sometimes, I really wish these generic source tags would be dated. For example, the dreaded:

  • source="microsoft/BuildingFootprints"

The Microsoft Building Footprints actually have a year-month-day associated with it:

So knowing which “version” those buildings are would be a huge help too, so you could do “AI Data vs. AI Data cleanup” on buildings that were completely untouched since much older imports.

(For example, I bet many 2026 Microsoft Buildings are probably in a better shape than the original 2018 ones!)

When I was scanning through Netherlands—a country where the government maintains all the address info and keeps it up-to-date on OSM—I was completely blown away with the quality of their:

This allows them to see when the thing was last updated, then quickly match the “current OSM data vs. official the government data”… and make adjustments on both ends as needed.

So similar to your really fancy “Toronto Address Layer” website you linked above in Post 1, you could see all the changes and updates as they’re happening each day. :) Then you could easily point and say:

  • “Hey! This addr:street has been wrong since 2020. Please update it!”
    • And their GIS people can make the adjustment too.

(Of course, a Netherlands-type-situation would be the ultimate goal to aim towards… but for now, we have to work with the patchwork of things we currently have.)

(And this fantastic Node import is an enormous step in the right direction!)

Now… time to chip away at more of those interpolations! :slight_smile:

I see in Ontario there are still this many addr:interpolations:

  • 2026.07.12 = 652,046
  • 2026.07.16 = 651,883
    • 163 down within the past 4 days.

So at this pace, we have about… 3999 more days to go!

:partying_face: Below 4000! Woot woot! Let’s go!!! :partying_face:

1 Like