James: In your message yesterday you state "The chances of GeoBase using OSM data is slim to none, in my mind. I think they need to have tighter control on the validity of data than OSM can provide. There are GeoBase people on here who may be able to dispute this, and I'm all ears."
I would reword the chances of "slim to none" to read "very high to high". There has been considerable behind the scenes work done since I broached the idea of working together in a posting to this list last March 23. The Canadian Council on Geomatics (a consultative forum on geomatics with representatives from all the federal, provincial, and territorial governments in Canada) has endorsed the idea and a fair bit of initial work has been done on system design and what institutional changes are required. We have also had discussions with some of the members of the OSM community in Canada as a part of our "homework". While we are not in a position to make any formal announcement yet, and I cannot guarantee that this initiative will proceed, I can express my confidence that it will proceed and there will be some kind of announcement soon. There are still some i's to dot and t's to cross but we are well along the process. Hopefully I will have some more definitive news in the next 30 days or so. So - keep the faith. We (GeoBase) like what you (OSM) are doing and hope to be able to work in a partnership soon! Mike Mepham Federal/Provincial/Territorial Liaison GeoConnections Program Natural Resources Canada E-Mail: [email protected] <mailto:[email protected]> Ottawa Regina Phone: (613) 992-8549 (306) 780-3634 Fax: (613) 947-2410 (306) 780-5191 Address: 06Ath Floor, Room. 646R 615 Booth Street Ottawa, ON Canada K1A 0E9 100 Central Park Place 2208 Scarth Street Regina, SK Canada S4P 2J6 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Ewen Sent: June 10, 2009 19:06 To: Corey Burger Cc: [email protected] Subject: Re: [Talk-ca] cleaning up after the GeoBase import On Wed, Jun 10, 2009 at 1:32 PM, Corey Burger<[email protected]> wrote: >>> Do people recommend joining the short sections of a single road, or >>> leaving them as individual ways between each junction? >> I'm leaning towards keeping the GeoBase short ways from junction to >> junction, and joining them with relations where it seems sensible. > Ugh, this is an ugly hack and not what the TIGER people have been > doing. I would just join the ways where they can be joined. The > reality is that in most urban areas you are going to have one or two > block ways because of all the transit relations. So, if I understand your suggestion, I should take all the ways that make up a road, and join them all together. ie. If my street is made up of 2 sections due to a junction in the middle, I should join the two section together, creating a single way. If we do this, then you loose the UUID which is associated with that GeoBase way. Is this a concern? Joining two GeoBase ways will create a UUID tag that would have 2 values. Joining a couple hundred GeoBase ways that define a stretch of highway would then give a single way that has a couple hundred UUID tags. I am in favour of the GeoBase import, which gives us a LOT of data for a very low cost (time and effort to import). However, trying to keep all of the GeoBase information associated is a bit of a pain. Because each section between junctions has it's own set of labels, you end up getting lots of labels on the map. By joining the sections, it make for better map rendering. If we don't need to keep the UUID, then what we could do with the import process, is have it merge connected ways that share identical attributes except for the UUID. This would still break the way where things like number of lanes, speed limit, surface type, bridges, and tunnels exist, but would create longer ways more like what I am used to creating by hand. The hundreds of section ways that define the highways and byways around here make it a whole lot more work to try and make changes and updates happen. Do we need to keep the UUID in place? I know we discussed this before the imports started, but now that I know what the data looks like, I would have lobbied hard for not inserting them into the database, and for joining identical way segments into longer ways. I think the UUID argument centered on being able to match against future import updates. Roadmatcher does a good job watching for existing roads now, and with nearly identical information in the database for updates, the matching criteria could tuned to look for even closer matches. From there, we could simply get a difference list, and use that to check for new roads, or discrepencies. The chances of GeoBase using OSM data is slim to none, in my mind. I think they need to have tighter control on the validity of data than OSM can provide. There are GeoBase people on here who may be able to dispute this, and I'm all ears. James VE6SRV _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
