[Talk-ca] [OSM-talk] Importing Government Data

[Sam Vekemans]

Actually,
I think the page is more of an essay to convince users that OSM should
be placed in hire value than the imported data.
Where all imported data would be treated as a nice addition rather
than users expecting updates, and not making contributions as they
know it will be available eventually, and they can just import it
then.

So the down side of this big import is that it could create an
unwanted expectancy among users. (which is probably why the talk list
has been quiet)

After-all, the 'inconvenient truth' is that it would be easier to wipe
out all the tagged items of 'highway=secondary/tertiary/residential'
(provided no 'relation or other extra tags' have been added.)
So for those mappers who contributed lots, (spent the last year
contributing what would amount to ghost lines) its a decision for them
on what they want todo:
manually merge/ wipe and replace / or trace.

I use the term 'Ghost Lines', as it has double meaning. In reference
to the KVR, Kettle Valley Railway,
http://en.wikipedia.org/wiki/Kettle_Valley_Railway and the abandoned
rail lines, which are slowly (but not fast enough) becoming part of
the Trans Canada Trail) as they get converted for recreational use.

This is why i am doing the 'Across Canada Trails' network, as i can
show trail users where those abandoned rail lines are, and send people
along the service roads, as eventually (with more notice of it) these
tracks will become converted .. but still, the paved road section
needs to be shown, as it's hard to ride a road bike on gravel.

I hope that puts a little more prespective about it.

I think it would make sense to create a second page for that
'inconvenient truth'? .. maybe. (i'll need to work on it a little)

Cheers,
Sam

On 12/21/08, Jochen Topf <jochen at remote.org> wrote:
> Hi!
>
> On Sun, Dec 21, 2008 at 02:08:46AM -0800, Sam Vekemans wrote:
>> Hi,I added a note on the wiki
>> http://wiki.openstreetmap.org/wiki/Talk:Import
>> As it lists 2 types of imports... i recommended a 3rd be used
>> Bulk Import.
>
> Well, the whole thing we are talking about are bulk imports. And as I
> wrote on the Import page there are two ways of going about it: One is
> doing it in one big event, the other is doing it piecemeal. So One-time
> imports and Community imports are just two special cases of bulk
> imports.
>
>> I think on the chart that AND is listed as a 1 time import, which is good.
>> However, with GeoBase and CanVec we are dealing with a ever changing
>> 'monster' ... literally :-)
>
> Thats a different issue in my opinion. Lets first get the initial import
> done and worry later about updating the data when new versions of the
> original data become available.
>
>> Where it's a hard concept for some mappers to fully understand.  (It
>> becomes
>> a social question... Do we want an outside source to tell use what us
>> 'right'  or do we want the outside source to just be an option. .. and we
>> decide if we want to use it. (as a WMS feed as a slippy map or as a JOSM
>> plugin) ..
>> .... but people didn't like the idea of importing it, and just not
>> rendering
>> it, '... would people go for it, if it was only for certain areas, and if
>> it
>> was easy to be fixing on potlatch?
>>
>> So far, all i've found was that the only way to cope with a new version of
>> available data, was to treat the original just as it would regular data.
>>
>> I've put out there the idea of 'tracing' but people seem weary about that,
>> does the wiki page 'Importing Government Data' clarify this issue? (from
>> your view)
>
> The page is a bit of a hodgepodge of different things. There are so many
> issues like data sources, licensing, update frequency, attribute naming,
> and many more. I think its needs a lot more work to sort out all of
> these. That why I suggest we leave this problem till later.
>
>> This idea of creating a complex 'Change detect' program, seems like it has
>> so many variables..... (at least i cant understand it).
>
> Doing this "properly" will, no doubt, be very difficult. I would go
> about it like this:
> 1. do the one-time import. don't worry about later
> 2. when new data comes available, create some kind of application where
>    people can see the old and new data (or OSM and outside source)
>    side by side or overlayed or something, let people sort it out
>    manually.
> 3. step-by-step build more advanced applications for specific issues
>    like I am doing with the OSM inspector now
>
> Jochen
> --
> Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/
> +49-721-388298
>
>