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

[datkin at ibycus.com]

There seems to be some general confusion around on exactly what is  
part of the Geobase dataset. (someone can correct me if I'm the one  
confused).

The Geobase road network is split by province, not NTS grid. All this  
talk about grids.

Next, most of the data on my maps comes not from Geobase, but from the  
Geogratis database (specifically the NTDB). Only the road network  
comes from geobase (not sure how clear this already was to everyone...  
some of the talk in the previous e-mails has been implying otherwise...)

 From the outside looking in (I don't do much with OSM stuff), I have  
a few questions.

How complete is the OSM dataset currently? (How many km of roads in  
Canada might be a good judge). If not very, then I'd say basically  
wipe the whole road network and use Geobase as a start, and then if  
possible transfer any additional parameters (street addresses/street  
names/speed limits etc) from the OSM database. (I know this might not  
be popular, as a lot of people have put a lot of work in to the data  
that is there, but the Geobase dataset is pretty darned complete, so I  
imagine you'd be overall a lot further ahead (close to 100% coverage)  
doing this than trying to integrate the datasets. Updates/additions  
could then be handled *much* easier (by continuing to associate the  
NID with the data). Addition of new roads with no NID could still be  
done, and later duplicates caused by syncing with the geobase dataset  
(as new releases become available) would likely be quickly handled  
manually as these would be in areas that contributors are interested  
in, and hence caught quickly.


Anyways, back to the grind stone. Three major final exams next week,  
so I better get to it!

Dale


Quoting Steve Singer <ssinger_pg at sympatico.ca>:

> On Sat, 6 Dec 2008, Michel Gilbert wrote:
>
>> I need some clarification about the parallel database (PostGIS). I am sure I
>> see the whole picture of the Geobase Import process. Who is going to host
>> the change tracking PostGIS database ? How are we going to access it ? I
>> prefer a process model that uses only osm database. I don't see how we are
>> going to maintain the PostGis database for users that access Potlatch or
>> JOSM. May be I have not understood the concept yet.
>
> I was thinking that the spatial database would only be used to generate
> the mappings between the OSM and geobase nodes.  Once a OSM node was
> deemed to be a geobase node the live OSM database would be updated to
> contain the geobase_nid tag.  You wouldn't keep the PostGIS database
> around, after the initial mapping process has done you will be able to
> get the 'mappings' from the OSM database by examining everything with a
> geobase_nid tag.
>
> PostGIS was only an example platform for generating automated mappings,
> you could probably do this in a JOSM plugin (that reads geobase files)
> and has geometric routines for determine if two lines a essentially the
> same.
>
>
>> Did we figure out the development platform ? The basic script to map the
>> road classes are written to work with JOSM ? or could it be something else.
>> I work with FME (Safe Software) a canadian company in BC. It is a great ETL
>> (Extract,Transform,Load) application. I know it is a commercial product but
>> it could help for the task we have. FME read osm and PostGIS formats and
>> offers many tools to find change detections and manipulate attributes and
>> geometry. FME has a large community, may be even among osm. It could be
>> interesting to find out.
>
> This is still open.  A lot depends on how much manual intervention is
> required in the process.  If the process can be automated then I think
> we'd want scripts that can be run in a batch fashion (so not a JOSM
> plugin) but if each tile is going to need a fair amount of manual
> massaging then a JOSM plugin is more appealing.
>
> We also have to consider what people are willing and able to develop
> in.  I wouldn't exclude FME on the basis that it is commercial it does
> restrict the pool of developers that could help with any scripting (and
> might have implications on where/how the import gets run)
>>
>> Michel
>>