[Talk-ca] Quick update

[Dale Atkin]

>-----Original Message-----
>From: richard at weait.com [mailto:richard at weait.com] 
>Sam said:
>[ ... ]
>> The idea of importing the next version of the ibycus topo.
>[ Why don't we import ibycus topo into OpenStreetMap? ]
>
>My understanding of Ibycus topo is limited.  I apologize if I'm getting
>this substantially wrong.  In my opinion the answer to your question is
>this:

Limited might be too strong of a word. There are a few features I've elected
not to include. These are mostly things which no one seems to have a use for
(like wells, and pipelines which are way out of date and confuse the maps).
The other thing I leave out (which is probably more to the point), are
database attributes which don't fit in the Garmin format.

>Ibycus and OpenStreetMap are two different projects with different goals.

True, although could someone clarify for me what the goal of OpenStreetMap
is?

Is the primary goal completeness? Or the user contributed data aspect? Or
the editability?

The reason I ask, is that there seems to be some contention here in the
discussions we've been having. The government data sources are (essentially)
complete as far as vector coverage. They are a little out of date in a few
areas (notably Quebec roads are pretty old), but from what I can tell from
the feedback I've been getting, they are pretty good. The OSM data seems to
be (in many places) fairly patchy, which honestly makes it pretty well
useless for a 'real map'. 

So, how 'complete' is the OSM database? How many km of roads exist in it in
Canada? My impression (possibly very mistaken) is that the data is maybe 80%
complete is highly populated areas, and pretty sparse in the more rural
areas. Is this not correct? For completeness, we can't hope to beat the
government, so why try? Why not supplement the government dataset by adding
more attributes to their data and adding missing features, but use the
government data as a base to build on? Yes, this means wiping out the
existing road set which has been carefully gathered (or more appropriately
putting it aside for the time being), but given what we have to gain, I
think organizationally this is more appropriate.

>What's wrong with Ibycus?
>
>0. Ibycus is restricted by the non-commercial clause of the cGPSmapper
>compiler.  cGPSmapper is also proprietary.  This limits my interest in
>cGPSmapper and in Ibycus.

Once its compiled, this is true. Precompilation, there are no restrictions
(from my point of view). *However* there is no way in heck I'm going to
upload my source files, for the simple reason that its way too much work. My
upload bandwidth isn't that great, and it would take *months* to get the
data online. 

>1. Is the entire Ibycus download in Garmin format?  Isn't the Garmin
>format a proprietary format that is (imperfectly?) reverse engineered? 
>Reliance on a proprietary data format is a very bad idea.  Why would we
>restrict OpenStreetMap with data in a proprietary format?
>
>2. Ibycus is described as "topo maps for Garmin GPS."  Wouldn't that turn
>the Canadian portion of OpenStreetMap into just a topo map for a Garmin? 
>That makes OSM Canada less useful than the rest of the World.
>
>3. Ibycus is not the data source.  Any conversion from original to Ibycus
>to OpenStreetMap is dependent on the Ibycus step.  OpenStreetMap can go
>directly to the data sources without relying on Ibycus.

Agreed. I'm not in favour of (although I don't mind) using my maps as a base
to go off of. What would make more sense, is to go to the original
datasources, and run the conversion from there. (of course we still have to
figure out what to do with the data already online...)

>The goals of Ibycus and OpenStreetMap differ in ways that make importing
>the Ibycus data to OpenStreetMap undesirable in my opinion.  Ibycus
>enthusiasts can use the open and Free OpenStreetMap tools to demonstrate
>the utility of Ibycus to build support for including Ibycus in
>OpenStreetMap in future.

Personally, I'm all for going from the original datasets. You loose less
that way, and continue to have the 'updatability'.

I have a question to throw out there...

Can someone point me to an API or tutorial or something for OSM that
discusses uploading manipulating the data (in a way that could be scripted)?
I've seen the web interface, but obviously that is no good for this kind of
thing unless one wants to spend days in front of the computer doing this.

I'm of the impression that there are:

a) a set of built in 'tags' that the rendering engine uses. (is there an
exhaustive list anywhere)
b) that the user can extend these tags to include custom information
c) that there exists an API for interacting with the database.

Wouldn't the most sensible way to add information be to take the original
SHPs and go from there? (including *all* of the database information). 


Dale