<br><br><div class="gmail_quote">On 11 February 2010 12:24, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
(I'm hijacking this thread which Nic started about legalities of imports<br>
on legal-talk, and moving over to talk)<br>
<div class="im"><br>
Nic Roets wrote:<br>
> My suggestion is that we should have a fixed, but simple procedure for<br>
> users who import data:<br>
<br>
</div>I think that every import should start with a deliberation on whether to<br>
import *at all*.<br>
<br>
Currently, I have the impression that many people are very trigger-happy<br>
when it comes to importing data. I believe that is running the risk of<br>
making OSM into one giant data rubbish dump.<br>
<br>
The old-style GIS community is currently working on several projects<br>
that collect what they call "metadata" - basically, because they know<br>
that there are so many different people with so many different data<br>
sets, they are working on ways to describe these datasets in a way that<br>
hopefully enables intelligent clients to present data retrieved from all<br>
of them as one coherent data set.<br>
<br>
This is of course extremely difficult and introduces many problems that<br>
one does not have when using just one huge database instead of thousands<br>
of different databases. But since many datasets are not static, you<br>
cannot simply grab them and pour them into one large database and be happy.<br>
<br>
What does this mean for our data imports?<br>
<br>
Data that is externally "owned" and maintained should not be imported,<br>
with the following exceptions:<br>
<br>
* if the data is so important for us (usu. as the foundation for other<br>
crowdsourced stuff) that we'd rather have and outdated version of it in<br>
OSM than nothing at all;<br>
* if we are confident that we, the OSM community, will do a better, more<br>
reliable, more thorough, and more timely job in updating the information<br>
than the original owner (this includes cases where the original owner<br>
has ceased maintenance);<br>
* if he are confident that we can easily synchronize our database with<br>
any updates made by the original owner to his data set.<br>
<br>
In all other cases it would be *much* more desirable to establish better<br>
mechanisms of merging OSM data with that other data in preparation for<br>
map drawing etc., rather than pulling it all in and having it rot.<br>
<br>
I would very much like to develop a kind of "litmus test" for imports,<br>
and get the message across that not every import is a good import (even<br>
if legally spotless). Today, even newcomers to OSM sometimes seem<br>
hell-bent on importing large quantities of data just because they can. I<br>
would like to remind people that OSM has a very lively culture of<br>
surveying data - and I'd rather have 1 sq km surveyed by a newbie than<br>
100 sq km imported.<br></blockquote></div><br>+1 globally.<br><br>Emilie Laffray<br>