On Mon, Jan 5, 2009 at 3:34 PM, Mepham, Michael <[email protected]> wrote:
> GeoBase nodes > > I can confidently tell you that GeoBase will not be creating a nodes only > data set for the use of OSM. That's okay, that was only Sam running in circles... he likes to do that, and we let him. 8) The OSM project wants ways. > Road Names and Addresses > Secondly, the data does not exist in some areas or even provinces. Or it > exists but is not available for free and unrestricted distribution. One of > the principles of GeoBase is that coverage is to be national. We cannot > just cherry pick the areas where data is easy but ignore the hard areas. Here I was thinking OSM could return the favour, and provide data back to GeoBase. There are probably limitations imposed that would make direct support from OSM to GeoBase impossible. Things like data reliability and such. > Thirdly, accuracy is important. This data will not just be used for pizza > delivery but also for emergency services delivery as well as by Statistics > Canada and Elections Canada for delivery of their programs. Hey, don't be dismissing a late night pizza delivery as a non-essential service. > One Segment vs. Two Segments > > A couple of posts have mentioned that for some reason the GeoBase data has > two segments for the same road, or part of a road. The answer to that one > is easy – there is a median or divider for that portion of the road. (Note > that short medians are not modelled into the data.) OSM does that as well, modeling a divided road as two distinct ways. One of the challenges as I understand it, is having some type of automated road matching system work. It's where GeoBase models a road as distinct segments between each node, whereas OSM can create a single long way that follows a path between a number of nodes. We need to match that 5 node long OSM way against 4 distinct GeoBase ways, and have the script realize they are functionally identical. > OSM data vs. GeoBase data > > I note with interest the discussions about whether or not to "replace" > existing OSM data with GeoBase data where the two coincide. The discussion > seems to recognise two options – replace the OSM or leave out the GeoBase > where there is duplication. I would like to suggest that there is a third > alternative that I have seen only hinted at so far and that is to merge the > two. Each data set has its own strengths and if they were to be merged > based on the strengths a superior data set could result. OSM has > attribution and linked data that exceeds what GeoBase has or was designed to > hold. GeoBase has a positional accuracy that exceeds what most of the OSM > data could achieve. It also has a set of basic attributes based on national > definitions and standards. > > I realise that there is a reluctance to lose the valuable work of volunteers > but the objective of the overall project must be kept in the forefront. And > if I read the posts correctly the objective is still to be decided and > agreed on. The objective is clear, it's the path to the objective. It's the job of merging the existing attributes onto the GeoBase NRN that's a stumbling block. > Maintenance > > It is our experience that creating a data set is the easier part of the > project. Keeping the data current and correct is harder but paradoxically > cheaper than the original mapping. While OSM doesn't incur the same monetary costs in acquiring data, we're still in the same boat. In order to merge the GeoBase data into OSM, we have to either expend the time and energy to develop an automated system, or expend the time and energy of hundreds of volunteers to vet and merge the data manually. > Of the millions of kilometres of roads > in Canada only a tiny percentage need to changed/added/deleted as part of > maintenance. The challenge is identifying these roads. Any thoughts or > suggestions from the members of this list would be welcome. We are always > trying to find more economical methods for keeping the data current. Perhaps this is a way that OSM can repay GeoBase... If the OSM project could create a change list of it's own, that would identify new roads added over a set period of time, it might be used by GeoBase to identify areas that they should turn their sights on. I'm sure OSM contributers will probably be out there mapping new roads as new areas of town are added before GeoBase hears about it through their partners. I've mapped new roads in Fort McMurray before the pavement was laid down. The crews working on the road looked at me funny, but OSM street mapping must go on! > Also – there has been some discussion about the need to re-load the OSM when > there is a GeoBase update. I would point out that GeoBase has begun issuing > change files that reflect only what has changed between two releases and > that should simplify keeping the OSM current. That would reduce the amount of data that would be required to be processed. OSM could act as a bird-dog pointing out new areas of development, then the municipal and regional partners could provide data back to GeoBase, whereupon OSM could import that data from GeoBase, and confirm it's accuracy! 8) It's all coming together, it's just going to take some time to make sure nothing gets squished into oblivion during the import. James VE6SRV _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
