[OSM-talk] immutable=yes Fwd: DEC Lands

[Andy Allan]

On Mon, Mar 9, 2009 at 10:22 PM, Frederik Ramm <frederik at remote.org> wrote:
> Hi,
>
> Russ Nelson wrote:
>> On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
>>>  If we can't change the data, what's the point of having it in OSM?
>>
>> Having consistent metadata and a consistent single-source API.
>
> That's exactly what I said in my first reply:
>
> Once OSM and its tool chain are established, everyone is going to want
> to have their data in OSM. ("Because then I only have to change my style
> file and the data is there on my map, instead of having to think about
> how to download it from elsewhere.")
>
> Which is ok, even desired, as long as the data is relevant and unless
> you consider the data your property that nobody must change.
>
> The power of OSM is not the API but the people. If you don't want the
> people then don't misuse our API to store your data just because it
> makes it easier for you to generate nice maps.
>
> By all means, set up another server with the OSM API running on it where
> you hand out accounts only to those who are privileged enough to change
> immutable data and adapt your toolchain to query both servers. (Or
> generally adapt the OSM toolchain to work with multiple servers.)
>
> I am absolutely sure that the dataset in question will, like any other
> dataset on the planet, contain errors. And if we find erroneous data in
> OSM, and know better, we will fix it in OSM, rather than asking some
> authority to please correct their data and then have a fixed update half
> a year later.
>
> There are a number of things one could do when working with such
> official data. As 80n has suggested, the data could be tagged and
> editors could make the user aware of the fact that someone was of the
> opinion that this data should not be changed and whether he's sure of
> what he's doing. It would also be possible to write software that works
> in a web-of-trust kind of way: "Extract these boundaries from OSM but
> only accept changes from users I trust; if other users have changed the
> data then go back in history until you find a change done by a trusted
> user". So anyone who is keen on extracting the "official" view rather
> than what OSM mappers made of it could do so.
>
> The cool thing about this is that it would follow OSM's mantra of
> filtering on the output side, not on the input side. The output you get
> would depend on which people you trust; whereas what you had been
> suggesting would be to just discard, in the database, everything done by
> people you don't trust.
>
> I maintain that it would be totally inacceptable to OSM to automatically
> revert changes to objects that are deemed "immutable".

+1

Reminds me a lot of the discussions about SRTM data. There's no point
in importing it into OSM since it's not community-editable (and it's
authoritative in its own context), but we've written tools to convert
it into OSM format for easier use. But we don't confuse the
on-the-wire-format with which db / project it should be sourced from.

Cheers,
Andy