Thanks for doing the wiki writeup, it looks pretty comprehensive to me.
My comments on the open questions:
addr:city=Toronto vs former municipalities. There are lots of factors to this: some say that addr:* should only contain postal data (Canada Post uses former municipalities) but I personally don’t find that distinction useful and that is already not the case for a lot of Toronto (e.g. parks - signed with addresses, but not recognized by Canada Post); some say that we should have whatever the posted address is (e.g. if a business advertises “Etobicoke” it’s addr:city=Etobicoke) even at cost of any useful consistency, which I don’t find very convincing. My personal suggestion would be to simply not add addr:city tags at all. The admin boundaries are already there, and Nominatim is currently good at using them to do searches and reverse searches, so not including the addr:city tag neatly bypasses the question.
Changeset comment template look OK to me. I would consider adding a URL to this wiki page somewhere in the changeset tags, so that it can be found more easily for anyone who might have questions later on. Any reasonable tag name should work, e.g. import_plan=https://wiki.openstreetmap.org/wiki/Toronto/Import/AddressPoints or something
Post-import monitoring: 90 days seems decent to me for catching initial issues, and if we provide a link to the wiki page in the changeset tags, people who have questions later on can get more info or find their way here.
Empty lots and recently demolished buildings: I am fine with either uploading these rows (if possible excluding obviously bogus places like if there’s anything in the middle of a freeway or a river) or leaving for manual review
Structure Entrance placement against building walls: I would suggest option a, because I can see myself being mildly annoyed by option b putting nodes on a building but not actually connecting them to the building way - that seems more annoying or confusing than useful
Address ranges (4611-4619 Steeles Ave W): I would be curious to see some more of these, to see if there is a trend we can discern about these being actually several addresses, or one building with a multi-number address. I’ve seen some of the latter, for example Way: 293-299 Spadina Avenue (184487246) | OpenStreetMap - as far as I can tell it’s one building with house number being verbatim 293-299[1] and not four addresses in a row. Based on that sample I would lean towards importing 4611-4619 Steeles Ave W as one node with addr:housenumber=4611-4619, but perhaps other examples indicate otherwise. What sort of “lettered ranges” are present? However, if this ends up being a big topic, we can skip all the ranged addresses for now and review them manually later.
possibly these were original numbers of previous buildings on the site? ↩︎
I removed static city value, makes sense that I should not write it down or clean it up. Postal Codes is not an open data, unfortunately, but be awesome to have it in OSM.
Empty lots and recently demolished buildings: I am fine with either uploading these rows (if possible excluding obviously bogus places like if there’s anything in the middle of a freeway or a river) or leaving for manual review
I just don’t want to involve too much human factor in it, on one end. So I think it’s best to pull everything in and let editors remove what looks out of place…
Merge Structure Entrance with walls.
Ok, will look into implementing this, but this breaks my “"do not update or delete OSM data” promise. Another idea is to just import them as pure addresses as well, not entrances – good enough, imho.
Address ranges (4611-4619 Steeles Ave W): I would be curious to see some more of these, to see if there is a trend we can discern about these being actually several addresses, or one building with a multi-number address. I’ve seen some of the latter, for example Way: 293-299 Spadina Avenue (184487246) | OpenStreetMap - as far as I can tell it’s one building with house number being verbatim 293-299 and not four addresses in a row. Based on that sample I would lean towards importing 4611-4619 Steeles Ave W as one node with addr:housenumber=4611-4619, but perhaps other examples indicate otherwise. What sort of “lettered ranges” are present? However, if this ends up being a big topic, we can skip all the ranged addresses for now and review them manually later.
Ah sorry, I think I misinterpreted. I was supporting the option “(a) leave as-is and let the JOSM operator drag/join each entrance manually”. But I focused on the “leave as-is” part and didn’t notice the bit about manually joining the entrance to the building way. I guess not joining the entrance to building way and uploading it hanging would have validators complain that the entrance isn’t part of a building way? In that case I am good with uploading them as addresses with no entrance tag.
Thanks! I’ll try to dig into these at some point.
From a really quick look, looks like there’s both actual ranges like 1-45 San Pietroway or 402-444 Lumsden Ave (looks like townhouses), and verbatim numbers like the 293-299 Spadina Ave I mentioned earlier.
Worked only for half a day. Processed 81 out of 1297 tiles.
Suburbs – super-easy – legacy housing zones like duplexes is almost automatic.
Suburbs – caveat – house numbers that were surveyed without street name – must carefully review, and later merge with building geometries.
Downtown – what is not that easy – every downtown tile had minor mapping errors like house addresses confused between two buildings. Buildings having correct numbers, but wrong street names. Each case requires looking at Mapillary, survey notes, item histories.
Fun bugs in Source Data itself – for example “10 Roanoke Rd” - “8 Roanoke Rd” pair confused; 98 Redpath Ave and 106 Redpath Ave pair confused. Any idea where to report it?
Typical funny issue – some one deleted address interpolation line, but not they end-points that become free-floating addresses. This again leaves me no choice but to whip up iD and move existing addresses to exact position.
Another quirk – alternative names – Sunny Slope had “alt_name=Sunnyslope Avenue;Sunny Slope Avenue” but my parser only expected, so it created dupes. My bad, fixed manually.
Off by one errors – surveyed addresses were shifted by one house. Tool highlighted it as “Found match, but it’s too far from where I would put it” – incredibly easy to miss, requires careful manual fix – shifting the position of existing addresses, making sure tool creates missed addresses and skips already existing ones. Example changelog.
Here is a slice of life video of the import process. Forgive me for bad sound, I live next to highway (Kingsway).
Observation – trip malls have so many addresses right next to each other. And this is a fragile data – one people will add a restaurant to pure address node, and later another person will delete the point when it’s closed.
Funniest thing happened – my own on-the-ground survey of new development gave me stress when reviewing city data. City data shows some real building numbers, but on the ground it’s all cloned building number with different block letters. See Clonmore Urban Towns
Incredibly annoying – same street named Linsmore Crescent vs Linnsmore Crescent. Absolutely not a Crescent, as a salt on the map gore wound.
Curious – in 2014 user came in and marked their old address on OSM. They have a lovely web 1.0 personal site with incredible domain name. So much personal history is there somewhere in OSM logs, if you think about it.
Mystical area I would call “Address Graveyard”. Probably need to move all these unto nearby mall…
Incredibly stressful fixing of address drift/off by one errors in Woodbine. Woodbine Avenue, Coleridge Avenue, King Edward Avenue – all need to be re-surveyed.
What I need to do as a side-quest – make a layer for JOSM that will show city address data, and street geometries (if we are allowed to use too).
I’m not too proud to admit I’m very sure I’ve deleted lots of vacant shops over the years. However, more recently I’ve taken to mapping the shop entrances as best I can, with the addresses tagged therein, precisely so that that sort of thing doesn’t happen.
Toronto is full of pagan superstitious – many building number 13 are skipped, so we often get address drift errors.
One of the only places where I went in and removed all existing addresses and added my own – too many mis-aligned ones and untouched for 8 years. Mystical land of The Fernways.
To improve my moral I added a button to go to easiest tile, instead of the closest one so I can work on something easy for a while.
Awekward moment for future mappers – some building had numbers as if if it’s a detached cottage, but it’s actually a duplex so importer adds a point with different number. So the mappers would have to manually extract address from building polygon into point, because importer skipped doing – it exists, does it not? This comes from our pormise to never touch OSM existing data with importer and only add (or NOT add) nodes.
45A Alvin Ave – another city point error, where OSM has it correct.
I’m seeing six rowhouses on the aerial, so numbers 24 through to 34 checks out, but the staggering between close to street and out in the backyard is just weird. Is this “mapping for the renderer” in City’s data, to give close-together address points more space to show up?
Also most of the addresses added on Roncesvalles are unit numbers for apartments above the stores, e.g. Node: 111A Roncesvalles Avenue (13865110904) | OpenStreetMap. What’s somewhat annoying is that some of the buildings got the extra nodes but others did not, even though all of them have apartments on second or third floors.
Did we ever resolve the numerous Canadian Open Data Licence(s) incompatibility with LWG terms? If not, these changesets should be backed out.
A decade or so back, the only reason that we got the Ottawa data was because the city agreed to provide the data to NRCan to be licensed under the Open Government Licence - Canada. Subsequently, the LWG allowed the Ottawa ODL 2.0 on 2017-03-02 but did not extend compatibility to trivially re-worded variants. As the wiki page notes:
For example, if the fictional City of Rotonto took the exact text of the Ottawa ODL 2.0 and merely replaced instances of “Ottawa” with “Rotonto”, the above minute indicates that the Rotonto ODL would still need LWG approval.
Is there a more recent LWG minute that explicitly approves the Toronto data?
(I’m aware that old guys gatekeeping the StatsCan Buildings import effed up the whole process for everyone, btw.)
I definitely noticed “mapping for renderer” with staggered points even for dupliex and townhouses. But more often I see a precise points close to duplex entrances. So, city’s mappers are also very human, and node positions are constantly being nudged by few meters, so they are constantly working on improving it.
I think it’s solvable by careful mapping, and having imported addresses is a small step in the right direction even though it does not look neat right now.
However, more recently I’ve taken to mapping the shop entrances as best I can, with the addresses tagged therein, precisely so that that sort of thing doesn’t happen.
