[Talk-ca] What we dont know from GeoBase

[Dale Atkin]

From: samvekemans at gmail.com [mailto:samvekemans at gmail.com] On Behalf Of Sam
Vekemans
Sent: Wednesday, December 31, 2008 9:43 PM
To: Richard Degelder; talk-ca at openstreetmap.org; Dale Atkin; Michel Gilbert;
Mepham, Michael
Subject: What we dont know from GeoBase



Hi all,

I'll try to separate the ideas into separate discussions :)



We don't know:



1. Is GeoBase/GeoGratis going to make available the dataset so that it can
be shown as Nodes ONLY?



Define “Nodes ONLY”. With my understanding of ‘nodes’ its trivial
(although IMO of limited usefulness) to back this out of the data that is
already provided.



We need this because;

1.1 - thats how any updates can happen. ... it's like a bar-code for
everything that is imported, so we know how to deal with it.



??????????????? Huh ??????????????? I must have missed something major here,
or some major misunderstanding of something because I don’t see how nodes
are going to help in the update process (at all). Rather they’ll make it
more difficult, and just confuse the issue.



1.2 For those areas of EXTREME osm coverage, is handy, because its easy to
spot where new mapping work is needed.



2. Re: Road Name/Numbers

Is geobase going to have all of the road names and numbers available for all
the provinces?  and when?



This is contingent on deals being made with the various provincial
authorities. Here is the current status:

http://www.geobase.ca/geobase/en/partners/index.html#nrn





We need to know this because:

2.1 StatsCAN already has available, so it could be an option to grab the raw
data directly from there?



This is an *EXTERMELY* bad idea. Trust me. The positional accuracy of the
StatsCan dataset is garbage, they even say so (although not in such extreme
language) is one of their write-ups. One might be able to use it to manually
transfer street names over (or a very clever programmer might be able to
work out some AI to do it, but that wouldn’t be me), but anyone trying to
use it for positional accuracy will be sadly disappointed.





2.1.1 but does statsCAN also contain Road numbers?

http://www.statcan.gc.ca/bsolc/olc-cel/olc-cel?catno=92-500-XWE <http://www.
statcan.gc.ca/bsolc/olc-cel/olc-cel?catno=92-500-XWE&lang=eng> 〈=eng



2.2 For the issue of QUALITY data.  we know that it not possible to manually
copy the road numbers FROM geobase data TO osm data. ...

but... manually copying all the other features FROM osm data TO geobase
roads, is much easier.



Why? Possible is a very strong word. I wouldn’t copy from geobase to OSM,
as there is way too much data for that. I don’t know how much data is there
to be copied from OSM to the Geobase set, but this might be more do-able
from a simple volume perspective.



3. Re: CanVec data

Then why has this dataset been created? ... why doesnt all the data which is
available ONLY on CanVec, just simply be merged into the GeoBase dataset?..



Geobase Only contains very specific data. It has a different goal than the
CanVec dataset. That being said, Geobase has done an excellent job of
getting certain data (roads in particular) available on a very liberal open
license, so it makes sense to pull the information from where its already
available.  For our purposes (or at least for mine) it makes sense to pull
roads from Geobase, rather than CanVec for the simple reason of not wanting
to wait for an update to the CanVec dataset.



We need to know this because:

3.1 It makes it rather confusing when looking at the canvec data list, to
see the chart "included in geoabase = yes" ... but then we dont know, which
one is more accurate?  ... why even include it in the CanVec list?



My impression, is that neither is ‘more accurate’. Instead that the data
is the same in both places.



3.2 It makes the referencing confusing, as it's a sub-reference which is
need.

3.3 Will the next version of CanVec data, only include CanVec data? .. and
no GeoBase Data?



Where do you get this idea from? I’ve seen no evidence of this.



I think that should cover it so far, sorry if some questions have already
been answered (sometimes it takes a little while for facts to settle in).
As we'd rather not be making decisions from assumptions.



Cheers,

Sam



I’m sorry if some of the above has come off as a little abrupt, but I’m
getting a little frustrated over here. I feel like I have a solution which
should work, and should provide a better overall mapset for everyone, and
provide means for updating with user data in a means that will be preserved
across revisions (which I think was the main problem with wiping out the
database and starting over with public datasources as a base), but I’ve not
really gotten any feedback on it. No one has told me “well that won’t work
because ‘x’. Or that isn’t in line with the OSM philosophy because ‘y’.




Instead we just seem to be talking in circles getting nowhere.



May I ask… Who here has the expertise to actually make something like this
work? (Sam, I don’t know your background, can you actually *do* much of
what you are proposing, and want the ‘go ahead’ from someone or are you
trying to convince people who can do what you’re proposing that what you’
re proposing is a good idea?)



Dale

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20090101/ab62c63b/attachment.html>