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.
