Address import for Toronto

Day 13 Progress Report, Final Day

Tiles processed: 1148/1297 → 1297/1297.

Another city data mistake – 10-80 Laidlaw Street.

Another city data mistake – 33 Wascana Ave is mis-placed.

Another city data mistake – 1110 Don Mills Rd and 980 Lawrence Ave E are confused.

I will start new thread to discuss the Interpolation Clean Up mapping party we want to have, maybe next week.

And for now i’m going off the map. Cheers!

4 Likes

Thank you!
You’ve turned a simple (boring) data import into something interesting to follow. A real saga!
:+1:

3 Likes

Hey @skfd, just checking: Node: ‪12C Cecil Street‬ (‪13890114625‬) | OpenStreetMap was created on May 27th even though I created Node: ‪12C Cecil Street‬ (‪13873163244‬) | OpenStreetMap on May 24th. Was the data running the import slightly out of date, or is my node not being taken into account somehow? I can delete the imported nodes, but just want to confirm what is necessary so that they won’t be reimported again.

I was running on a day old Geofabric dump so this can definitely happen. Thank you for fixing the duplicates!

1 Like

OK, another question:

Node: ‪62 Douro Street‬ (‪13859192051‬) | OpenStreetMap was created even though Node: ‪62 Douro Street‬ (‪6150044838‬) | OpenStreetMap has existed for years. Was the script expecting an entrance tag on the existing node?

Similarly Node: ‪70 Douro Street‬ (‪13859192052‬) | OpenStreetMap was created even though Way: ‪70 Douro Street‬ (‪58335951‬) | OpenStreetMap exists. But even more confusingly, other addresses in that building like 64 or 66 Douro were not.


And now a complaint: nonexistent addresses. I’ll use 1029 King St W since I am familiar with it. The apartment building and all POIs on ground floor, except for one, are 1029 King St W. The one exception is the West Neighbourhood House at 1033 King W. However, the City apparently has, and so we’ve added, addresses from Node: ‪1007A King Street West‬ (‪13859192050‬) | OpenStreetMap through to Node: ‪1027 King Street West‬ (‪13859192037‬) | OpenStreetMap.

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.

Node: ‪62 Douro Street‬ (‪13859192051‬) | OpenStreetMap was created even though Node: ‪62 Douro Street‬ (‪6150044838‬) | OpenStreetMap has existed for years. Was the script expecting an entrance tag on the existing node?

Similarly Node: ‪70 Douro Street‬ (‪13859192052‬) | OpenStreetMap was created even though Way: ‪70 Douro Street‬ (‪58335951‬) | OpenStreetMap exists. But even more confusingly, other addresses in that building like 64 or 66 Douro were not.

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!
1 Like

OK noted!

Glad to hear we agree on this :sweat_smile:

Instead of deleting them, I could instead tag them as not:addr:housenumber=* and not:addr:street=*? :thinking: 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 (:person_raising_hand:) 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 :sweat_smile:

Thank you for this, I think I will work on some kind of tracking tool as you suggest. Will report when I have something.

Ooh, so it mean we can do the same to all these other places?!

If they have address open data and if the local community if one exists wants it, yeah I guess?

Someone was posting about Hamilton addresses in Hamilton address open data import

1 Like