Toronto city has released addresses dataset as an open data with OMS-compatible license. It is not an interpolations like CanVec, but actual address nodes – much more useful.
I use this data as a reference in manual Josm edits. But it feels like it’s time to setup an import, maintenance flow for it.
I am new to this task, and would love to learn the process. And also request community’s help – who know maybe someone has the skill and tools to just run it with no problem.
Any suggestion, ideas, heroes who will take over?
My Plan
I think I will start by reviewing this recent node import for Toronto.
Thanks for suggesting this. It could be a good project to improve OSM in Toronto.
I took a quick look at the City data comparing it to parts of Parkdale where I surveyed and aligned buildings manually, and it seems good. The markers were within the mapped buildings and I didn’t spot any obviously wrong data. From a spot check, some fairly recent new addresses (created after 2020) are also present in the data.
One thing I did notice is that in some cases the City data has separate nodes for residential units within a building, but in other cases it’s just one node for the entire building regardless of number of units.
Have you decided if you’d rather import nodes, or merge the addresses into building ways where mapped?
If only importing nodes, we might end up with some points that are residential unit addresses that share a building. But in my spot checks this only went up to 5 addresses per building (20 Triller, 20A, 20B, 20C, 20D) so that’s not too terrible.
If trying to merge into buildings, there would be a need for some interpretation, particularly distinguishing between attached houses and residential units within one building.
This is probably more of a problem in Old Toronto, so we could start by doing the suburbs first, I would guess addressing is cleaner there.
For the record, some examples to illustrate difficulties:
44 Galley Avenue and 44A Galley Avenue are separate semi-detached houses and show up as separate addresses in the City data. However, the City data also has 20A Triller Avenue and 20B Triller Avenue as separate addresses, but from survey they’re within one building.
There are also some buildings that have two addresses without suffixes but really are one building: 24 and 26 Triller Avenue (one gas meter seen for the whole building), 49 and 51 Marion Street
We might be able to usually distinguish semis on aerial imagery, but in some cases (like overhanging trees or weird roofing jobs) it might be hard to determine if an “A” address is a separate building or a unit within a building without a street-side survey.
Just to illustrate how ridiculous Old Toronto addresses get, 54 Galley Avenue and 54A Galley Avenue are separate buildings about 30 metres apart.
I think overall strategy is to create address nodes, merge with existing address nodes (and polygons if it can do it) using Josm Conflate plugin. Toronto has lots of duplexes that are maped as one polygon and it makes sense to put two address nodes on them.
Merging address nodes into building polygon it is inside of makes sense but i dont know if there is a tool for that. Will mark it as a n optional next step. But I think a single address point on a building is still good and valid state of the map.
In that case I would just let them be nodes inside a building polygon, if they give more information.
Oh, did not think about that nuance. I was thinking of just making neutral address node, without mentioning a type. Will have to look into that closer and read wiki.
Great examples at the end! I think it will also be handled by the rule — merge single address into building, let multiple addresses stay nodes. That handles semis either they are mapped separately of as one polygon.
Things like 54 and 54A are completely different addresses to me so it is not a problem. Might need to review medical and educational campuses — they might make nuances like wings and annexes
Do I understand correctly that this would mean all the buildings in the city will have addresses? (Except for confusing cases with multiple addresses in one building.) All the work being done by patchwork by people with Street Complete and Every Door will be completed city-wide in one big data load?
That’s the ambition, and it cam precociously from doing address surveys with Street Complete. Tricky thing are Postal Codes and City values — can not survey these.
The city is Toronto. We have uses of stuff like addr:city=Etobicoke but that’s wrong, it should be addr:suburb at most. What Canada Post calls the “postal city” isn’t what the city is. There’s been several discussions on the forum here that addr:* doesn’t have to be the same as a postal address if they conflict.
Another point is tagging addr:city is not required on points or ways that are unambiguously within an administrative boundary relation for the city - which is the case for Toronto (and I believe most/all of southern Ontario).
On postal codes I agree, except where businesses display those for surveyors to see.
Let’s say there’s a residential street where someone surveyed one side and gave those houses numbers. Would this leave them as is, since all of the buildings were done? On the other side, the plan would be to add the addresses to the building polygons (where possible), not drop nodes inside them.
I’m asking because I’m trying to get a better sense of what the map will look like after this is done, and what dilettante editors like me could do when out walking around with Every Door open.
What would happen to the CanVec address interpolations?
On another note, if this all works out, is there a way to get the word out to news sources? The City would be interested, since it’s a great application of their open data. Improvements to public life, helping businesses, all that, the major talking points are obvious to anyone here. Is there an OSM or Toronto group that could do that sort of thing?
Yes, I would guess so, unless there’s address points that were missed somehow and look like they should be added (i.e., they don’t look to be units in an apartment building).
Tagging polygons/ways would be optimal, but in some cases nodes could be necessary, for instance when it’s semis or townhouses that are difficult to distinguish on aerial imagery. Because the position of the address points seems quite accurate, having nodes would still be better than interpolation lines.
Start tagging building:levels=* and maybe roof:levels=*, refining or correcting building=*, perhaps building:use=* to indicate cases like a former mansion converted to separate units, building:units=* to indicate number of units (can be seen on some buildings by counting mailboxes or doorbells). The latter tags unfortunately have to be entered manually in Every Door, but I think the first three are presets. Street trees and hydrants are another possibility. Or focus on shops on main streets instead of on residential buildings - a lot of them are quite out of date.
They would be deleted where all addresses on a block have been mapped. I do that now too, as cleanup after my Every Door walking surveys.
In my experience there isn’t an active Toronto group right now. There’s active mappers but I haven’t really seen an organization.
Noting that the City just launched a new awards program to showcase projects that use open data. This year might be a bit early depending on how long this project takes, but could be a good submission assuming the awards come back in 2025.