Talk:Triplinx Metrolinx Import Plan

From OpenStreetMap Wiki
Jump to: navigation, search

Did you follow the instructions in the Import/Guidelines before doing this import? --Scruss (talk) 03:37, 2 February 2016 (UTC)

Some Comments

Hi all,

I think I may be coming late to this, but I wonder if address range imports are a good long-term strategy for moving toward more complete data in the greater Toronto area. I know ranges are used already throughout OSM, particularly around Toronto, and that certain applications use and digest them... but the address ranges that are currently in place around the region in OSM seem to me like kind of a big mess. I'm not super-eager to see a whole bunch more of them if the quality is going to be about the same and if their creation isn't the result of a more grassroots editing process.

For example, I've seen several spots where an address range was placed on a tiny block where it could only possibly refer to two small buildings. Not much of a range! The line was not even aligned such that it was placed across those buildings. In other places, there are address ranges on streets with nothing at all fronting on them. These are addresses for trees I guess. Obviously, it would be better to tag all buildings directly or to put a node in each of them, and ranges are a second-best data format that is less effort-intensive to create. Well, here's my thought: building coverage in the region is pretty shitty right now, and I can imagine, if the region goes the same way as have many other cities in the last few years, that we could in a few years time be looking at the possibility of a big building import where each building has an address or address range attached just to it. To my mind, such an import would be about 100x more desirable. Would the creation of a ton of address ranges now create a conflation problem down the road as buildings with addresses are either imported or added manually? I don't know much about the state of open (building) data licensing in the region, so maybe hoping for a near-future building import is wildly optimistic?

In summary, buildings with attached addresses seem like a sensible end goal, with address ranges as a tolerable intermediate step. Would it be better to go straight to the end solution?

Nate Wessel (talk) 22:23, 4 February 2016 (UTC)

Hi Nate — good points. Addressing in Ontario is weird: street addresses can be completely disconnected from buildings. Similarly, in rural areas, buildings may not have an address. Maybe we should aim for a “No short address ranges” guideline to avoid those two-house ranges? Provincially, there isn't a good source of open building data (welcome to Canada!) but Toronto's 3D Massing Data set could be worth looking at. Similarly, the city has address points, but the Triplinx crew's federal source is aggregated from municipal data, so it would be much the same. Mojgan and her team's goal was to provide infill address ranges where there were none so that Metrolinx users could use trip planning based on OSM data. This is a pretty worthwhile goal, I feel --Scruss (talk) 14:31, 5 February 2016 (UTC)
I think a no-short-ranges rule would be a good idea, maybe defining that both for short ranges (house numbers 1-5 or something) and short distances (no ranges less than 75m perhaps). There was one other concern that occurred to me yesterday as well: since Metrolinx will naturally take some role in amending the data over time to get their trip planning working well, I would just want to make sure that the software they're using is designed to work as well or better with individually tagged nodes and buildings as/than it is with address ranges. That way their fixes to the data, as the trip planner is concerned, would tend to push the data away from ranges if anything and toward more fine-grained data. Nate Wessel (talk) 19:45, 7 February 2016 (UTC)
From talking with Mojgan, it seems that address ranges are good enough for them, and this was inserting address ranges for which there was no data before. And I'm okay with that. --Scruss (talk) 11:12, 9 February 2016 (UTC)