[Talk-ca] What we dont know from GeoBase

[James Ewen]

On Mon, Jan 5, 2009 at 3:34 PM, Mepham, Michael
<Michael.Mepham at nrcan-rncan.gc.ca> 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