[Talk-ca] cleaning up after the GeoBase import

Mepham, Michael Michael.Mepham at NRCan-RNCan.gc.ca
Thu Jun 11 19:09:24 BST 2009


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:  Michael.Mepham at NRCan.gc.ca <mailto:MMepham at NRCan.gc.ca>  

 

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: talk-ca-bounces at openstreetmap.org
[mailto:talk-ca-bounces at openstreetmap.org] On Behalf Of James Ewen
Sent: June 10, 2009 19:06
To: Corey Burger
Cc: talk-ca at openstreetmap.org
Subject: Re: [Talk-ca] cleaning up after the GeoBase import

 

On Wed, Jun 10, 2009 at 1:32 PM, Corey Burger<corey.burger at gmail.com>
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

Talk-ca at openstreetmap.org

http://lists.openstreetmap.org/listinfo/talk-ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20090611/24217c3d/attachment.html>


More information about the Talk-ca mailing list