[OSM-talk] immutable=yes Fwd: DEC Lands
Mike Collinson
mike at ayeltd.biz
Fri Mar 13 09:42:54 GMT 2009
At 06:36 PM 12/03/2009, Russ Nelson wrote:
>On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote:
>> . However, I reject the idea that there is any data that belongs in
>> OSM that "makes no sense to edit". If you can't edit it, then by
>> definition it shouldn't be in a wiki-style map.
>
>No one has been able to refute my claim that if someone would enter it
>by hand, it belongs in OSM regardless of its source. And if it comes
>from surveyed data, then it makes no sense to edit its position.
>Metadata, perhaps. But unless you've been out in the field with a
>theolodite, you have no business changing the location of the NYS DEC
>Lands position.
Watching the discussion, I'd conclude as follows:
The primary OSM database is a collection of, by definition, mutable data. That is the "wiki" principle. Whether it actually makes sense to edit parts of it is therefore not relevant. Provided that the original licensor's terms permit, anyone is free to put a *copy* of reference data into the OSM database. The original immutable reference source still stands. The copied data can be tagged with a source and a request or suggestion made that it should not be altered ... but that suggestion cannot be mandatory. So immutable=yes is confusing but by all means place immutable=recommended.
I used the term "primary OSM database". At the moment, the primary OSM database is the only database that serves data according to the OSM API and XML schema (?). I foresee that will change although personally I would drag my feet on it until the primary OSM database has even more clearly established itself as The Source. Optional datasets will however emerge and maturing editors and renderers will adapt. Sets of coastlines at different resolutions and sources, scientific datasets, school projects, where I went on my holidays ... and reference datasets at higher resolution and authority than general contributions. That, I suspect, is the true long term solution to Russ' dilemma.
Mike
More information about the talk
mailing list