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