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

[Sam Vekemans]

Hi all,
Thanks dale, so perhaps i need to ask the OpenStreetMap Foundation
this question then.

Does the foundation agree that the license of geogratis.ca is
compatable with that of the openstreetmap foundation?

If so, this would then open the door to a whole lot more data.

Thanks,
Sam Vekemans
Across Canada Trails

On 12/6/08, datkin at ibycus.com <datkin at ibycus.com> wrote:
> 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
>>>
>
>
>
>