[Talk-ca] GeoBase Import - Where we stand now

[Steve Singer]

On Sat, 6 Dec 2008, Sam Vekemans wrote:

> IF the prime purpose IS to complete the road network across Canada, then  in
> doing so this will cause issues.  This is because, technically speaking.
> The GeoBase road database IS ALREADY the complete road network across
> Canada. Period.  With future updates, this database, will ALWAYS be the
> complete road and official road network for Canada.  It's a federally funded
> database, with the goal of being the complete network.
> So .. no matter how we twist and turn it, it will still be complete.

I think the purpose is closer to what you describe below (an editiable) but 
I am not sure I agree that the geobase data is always 'complete'.  When new 
roads are built it can take time for those roads to get into geobase. During 
that time the geobase data is 'incomplete'.  Also remember that different 
parts of the country are in different stages of 'completeness' the geobase 
site talks  about this.

>
> Soo... However, if the prime purpose is to create a totally free and
> editable map of the world, we must then treat GeoBase with the same level of
> indifference that we do to user:Acrosscanadatrails.  Just so happens that
> there will be a few users who are importing the data, and have spent a real
> long time gathering tracks and points, and converting the points into ways,
> and labeling them, and is ready to start bringing in the data.
>


<snip>

I agree data imported from geobase shouldn't be given any sort of special 
standing above what a normal user might enter (users are free to add any 
special mapping tags to the nodes as well).

>
> I propose that we start with tile 092F04 (Tofino, BC) as thats what i did,
> and probably needs the basic script to get the road class right.
> Or maybe 082E14 (Kelowna, BC)
> or maybe the 030M04 (Hamilton, Stoney Creek, Ontario) but there is alot of
> OSM coverage, so i think it would make sense to work with less OSM coverage
> areas 1st... so to tweak the import script 1st. and to see what it's like
> for fixing GeoBase data to conform with OSM standards.
> ... or even 001K10 & 001K11? (south of Saint Johns NFLD) and importing all
> the kinds of data available for it?

Your referring to an 'import' script in the above.  What import script, is 
this Jason's python script in the OSM svn repo, a modified version of that 
script, some other script or something that still needs to be written?

Looking at the wiki I see three approaches we've been discussing

1. An approach using a spatial database to try and generate automatic 
mappings between OSM and geobase nodes

2. Import tile by tile excluding OSM areas with lost of data.  The person 
that is manually importing each tile would be responsible for eliminating 
(or merging) the duplicate streets.

3. Use a JOSM plugin to display geobase data as a second layer and have 
people manually trace the geobase nodes into the OSM layer.


Your referring to proceeding with (2) or am I misunderstanding.


Do we have a handle on:

a) How many tiles have 0 OSM roads (but do have at least 1 road in the 
geobase nrn)
b) How many tiles have OSM coverage similar to Tofino BC (or any your other 
examples from above) , and how much manual effort does it take someone in 
JOSM to manually fix up the duplicate ways following a OSM import.
c) How many tiles (that have roads) are left over?


Tiles in group (a) can be proceed once we've agreed on a mapping of geobase 
to osm tags.  I think it will be easier to obtain concensus to start moving 
forward with group (a) while people are still thinking over solutions to 
merging duplicates.

The answer to the questions I pose in (b) might tell us if it is worthwhile 
pursing an automated mapping approach and if an approach requiring tile by 
tile human intervention is feasible.

I suspect the major population centres will all be in group (c).

>
> Cheers,
> Sam Vekemans
> Across Canada Trails
>

Steve