+1 for that!!!
I could easily create and store all the canvec2osm created files on my
GoogleApps website www.acrosscanadatrails.com
(as well as the geobase2osm NRN data, which is already being archived on
http://www.mediafire.com)
I would of-course have it all in a single layer, (but better to have it as
separate OSM files feeding to the same source) ... better for what? I don't
know... it would solve the problem for when the new canvec/geobase DB is
available (+ the UUID's will be held in safekeeping) :-)
These files can be copied to a master server somewhere. (The Bulk Import
o-sphere, which is just below the OSM-node-o-sphere... which is WAY above
the blog-o-sphere!... and close to the GPX track-o-sphere) ... plus the map
can ALSO be rendered and available to view, for when using potlatch :)
So having the ability to only 'pull' a select section, to use it, select it
all and 'drop' in onto the current 'osm data working layer' (... as well as
the ability to 'select items which are to be uploaded' would really help.)
Having your userID with the automatic reference tag added ie.
"canvec:Acrosscanadatrails" for times when you download data.
(that's covered because you now have to 'login' BEFORE you upload any new
data to the server.)
Also, having all the tags that are stored as reference tags also come in as
the user 'pulls' the data from the "Bulk Import Data Layer"
So then only users who have added themselves to the 'Bulk Import Data'
database acess list can submit data to this, using the "DATASOURCE:username"
tag. (and have agreed to the ODbl licence?)
FYI, AFAIK, just because i edited the rules.txt file and created the
canvec2osm.bat (DOS instructions file), that wouldn't necessarily mean that
i am the "created-works" importer, i just created the "tool" so the
creativity was in the 'linking of the data', i made the chain links to fit
together, but not the entire spool of chain. ... PLUS, the tool was created
acquired knowledge from others.
This MAY solve the database Quagmire :-) ?
Cheers,
Sam Vekemans
Across Canada Trails
Message: 10
>
Date: Sat, 14 Mar 2009 20:42:34 +0800
>
From: Eugene Alvin Villar <sea...@gmail.com>
>
Subject: Re: [OSM-talk] immutable=yes Fwd: DEC Lands
>
To: Jukka Rahkonen <jukka.rahko...@mmmtike.fi>
>
Cc: talk@openstreetmap.org
>
Message-ID:
>
<a07a5a700903140542g20a529bfq3c7cca73d3474...@mail.gmail.com>
>
Content-Type: text/plain; charset="iso-8859-1"
>
> On Sat, Mar 14, 2009 at 7:33 PM, Jukka Rahkonen
>
<jukka.rahko...@mmmtike.fi>wrote:
>
> > Why not to store this kind of datasets as own layers in the database?
> DEC
>
> data
>
> could be on its own, non-editable layer, but if there's something that
>
> people
>
> would like to edit those features could be copied or lifted to anothet,
> OSM
>
> layer. That would make DEC updates easier as well, they would just update
>
> the
>
> DEC layer. The same approach would suit other data of similar nature as
>
> well,
>
> like TIGER or cadastrial data.
>
>
>
>
>
+1
>
> Having multiple separate "layers" in OSM would be good for various
> purposes.
>
The GPS traces "layer" is already one we use.
>
> Eugene / seav
>
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
