[Talk-ca] Merging OSM + Geobase

[William Lachance]

On Thu, 2009-03-26 at 13:46 -0600, James Ewen wrote:
> On Thu, Mar 26, 2009 at 1:00 PM, William Lachance <wrlach at gmail.com> wrote:
> 
> > I've been following the discussions about the geobase import with
> > interest. There seems to be some concern about how to correlate the
> > existing OSM data with the Geobase dataset. In particular, how do we get
> > the superior positioning and connectivity of geobase without blowing
> > away all the great work people have done tagging their manually inputted
> > ways?
> 
> I keep seeing people talk about the superior positional accuracy of
> the GeoBase data. From the sections that I have interacted with, I
> would find it hard to support this statement. The position accuracy of
> the GeoBase data that I have dealt with is very easily recognized as
> much less than the OSM data.

It probably depends on region. I find the geobase data around Halifax to
be remarkably accurate. If that isn't the case for other parts of
Canada, we could easily add a flag to a merging tool to favour the
positioning/naming of the existing user-contributed OSM data if that
were preferable.

> > One alternative which I haven't heard mentioned is the possibility of
> > _merging_ the two datasets.
> 
> That's what is happening now, using a script that watches for existing
> roads, and skipping them. The issue is stitching the newly imported
> roads to existing roads.

Right, so what I'm proposing here is that we don't skip the existing
roads, but merge them. In the case of the HRM, I'd propose simply
replacing the existing positioning data with the geobase information,
which should solve the issue of stitching roads together. 

I do understand that in some cases elsewhere in the Country where you
might want to keep some of both. In which case...

> The problem appears to me to be the fact that the existing ways will
> need to have nodes added to them for the imported ways to link to. The
> software being used right now does not do that, but rather just stops
> the import at the next closest node on the imported way. There will
> need to be some type of decision making process happen in the import
> scripts that either a) finds a node on the existing OSM way that is
> within a specified distance from where the imported node should be, or
> b) create a new node on the existing way, and connect the imported way
> to the newly created node on the existing OSM way.

> This would solve the issue of having the two road databases being
> separate, but it would still require manual intervention to fix the
> inevitable problems.  If you look at the example from Camrose, you
> will see that some GeoBase roads stop short of the OSM way, while
> others cross the OSM way. If a new node was added and connected to the
> node that crosses the OSM, it will look like there's a mini off ramp
> or something.

Maybe I'm not understanding something, but why couldn't you just add a
new node to both ways at the point of intersection? I don't see why that
would look like a mini off ramp -- on the contrary, it wouldn't change
the actual geometry of either way at all!
-- 
William Lachance <wrlach at gmail.com>