I don’t mind one or two addresses in an empty lot, but this is 12 addresses within one building that do not currently exist and have not existed in at least 20 years since the building was built. They only exist in the sense of an address interpolation (a line between two known addresses), as the next building down the street is 1005 King W. But they were added as points, not as an interpolation line; and anyway we delete an interpolation line once all addresses have been surveyed. Crucially, they cannot be verified on the ground.
And the inconsistency is jarring - why 1007A and 1007B, but only one 1015 with no A or B? Only thing that comes to mind is that 1007A and 1007B might have existed 30 years ago before the condo was built, but they surely don’t now.
I would suggest creating a list or a database of addresses that exist for the City but not in real life, so they will not be reimported if we ever rerun the import.
The address points in 1029 King W weren’t inherited from old buildings – there was just one big Massey Fergusson factory on the site before the condo was built. They were assigned to each of the possible entrances or retail spaces on the podium. That’s why some of them have A and B and some don’t: They had to add 14 addresses between 1005 and 1029.
In practice it seems like they aren’t used but I think that makes it more of a historical oddity than a rogue interpolation by the city.
Those were my mistake as operator, it got pulled into spot check and I approved them to be uploaded even though they were flagged as MATCHED. Sorry about that!
And now a complaint: nonexistent addresses
This is something big for sure that needs to be addressed. Ideally we want to have a database of city addresses in OSM, minus the errors in City Data, and minus these legacy addresses that no longer exist. So, the error and legacy address needs to be tracked somewhere, I recorded some things in the progress report but not as structured data.
One option is to keep these legacy addresses in OSM, but not as addresses visible to users but as something with some king of lifecycle tag.
Another option – sidecar database that enriches City Data with local knowledge / OSM mapper work… This would require some kind of feedback mechanism, which I can make for sure and would love your ideas!
Instead of deleting them, I could instead tag them as not:addr:housenumber=* and not:addr:street=*? but that depends on mappers knowing about this tagging, and it’s not as easy as hitting “does not exist” in apps like Every Door.
I was initially thinking of a tool that would keep track of all the imported nodes, periodically check if they have been altered or deleted, check if as a result that address no longer exists in OSM, then note the changeset that made the change, and do manual review of that changeset. Then we’d see if there was any comment in the changeset indicating that the address does not actually exist. But that is a lot work to build a tool that would depend on mappers writing those comments explicitly, which they might not, especially if they’re walking around surveying with Every Door or similar apps.
Personally I would be happy to fill out a form about addresses that do not exist, to be added to a list hosted somewhere. We might not get a lot of take-up, as most people would either just delete the addresses from OSM (or even just leave them in anyway), but it would let people who care the most () communicate that data. The form could be as simple as house number, street name, and optionally OSM username of the person reporting. Then a quick manual review before adding it to the Nonexistent List.
Or instead of a form it could be a wiki page on the OSM wiki somewhere under Toronto/*? Depends if it’s easier for you to host a small database or to parse MediaWiki tables, I know from experience the latter isn’t trivial