[Geodata] wiki-nature geodata aggregators

nicolas chavent nicolas.chavent at gmail.com
Tue Jul 28 11:26:29 EDT 2009


"Along with this,  as an entity considers tagging a blessed version for
whatever purpose, as the trunk continues to change, having good "diff" tools
becomes important for the authorities such that they can monitor what is
changing and can respond accordingly (accepting the edits, going back in and
saying "no, we surveyed this with super new fangled gadget and know that it
is right" etc)."

Curious about experienced proven solutions for these "diff tools".
Curious as well of documented cases where by "Authorities" are using VGI
datasets (of which OSM can be a paradigm) the way outlined above by David.
This aspect of data sharing has been touched in some disussions at State Of
The Map 2009. And something similar to what David outlined would be being
thought of by the canadian NMA which shared its base map data (Geobase) such
a with OSM. In such a scheme, OSM edits to the shared version of Geobase,
would help the NMA into managing their update cycle more efficiently.

Thanks in advance for any element on this.

Best
N.

On Tue, Jul 28, 2009 at 6:59 PM, Andrew Turner
<ajturner at highearthorbit.com>wrote:

>  David William Bitner wrote:
>
> On Tue, Jul 28, 2009 at 9:25 AM, Arnulf Christl <
> arnulf.christl at wheregroup.com> wrote:
>
>> > I'll also add that just because a geodata set has a stamp or
>> > "authority", and some apparent quality assurance process, does not
>> > mean that the resulting data is any better, or the process any more
>> > full proof, than the many eyes approach of OSM.
>>
>>  True. At the same time for some it does make a difference whether an
>> authority of some kind stamps information or not. OSGeo may well (be)
>> develop(ed) into a kind of authority because it is not ...
>
>
> Often times when liability is concerned sometimes -- often more wrongly
> than right -- it is necessary to use an "official" version of something
> merely for the reason that you can then pass-the-buck if there are
> problems.  Along the same lines, when you are doing work that could end up
> in a courtroom or more simply end up getting questioned or audited or ....
> it is necessary to build off something that is at least a snapshot such that
> those who are questioning/auditing/whatevering you can go back and recreate
> your work from the same version of the data that you had used.
>
> As with source code, versioning, having snapshots, sometimes having a
> branch away from trunk that gets released (think a snapshot of OSM at a
> certain time that has been deemed by a local authority as acceptable for
> planning work and tagged as such) can be very valuable things that can help
> to bridge the gap between the "wilds" of crowd sourcing and the need for
> control of "official" datasets.  Along with this,  as an entity considers
> tagging a blessed version for whatever purpose, as the trunk continues to
> change, having good "diff" tools becomes important for the authorities such
> that they can monitor what is changing and can respond accordingly
> (accepting the edits, going back in and saying "no, we surveyed this with
> super new fangled gadget and know that it is right" etc).
>
>    There has been some good brainstorming on this idea at a few recent
> conferences and sessions. An entity could "sign" a snapshot/region/way.
> Calculate the MD5 hash, apply your GPG public key, and you now have an
> 'official', or accepted, version of data. This is similar to how Git (and
> other DVCS tools) work.
>
>
> _______________________________________________
> Geodata mailing list
> Geodata at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geodata
>
>


-- 
Nicolas Chavent
Norplan, Abu Dhabi
GIS Expert and Project Manager
Mobile (UAE): + 971 56 602 35 15
Email: nicolas.chavent at gmail.com
Skype: c_nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20090728/bd9e53a5/attachment-0001.html


More information about the Geodata mailing list