Hi,<br>Im just tagging on to this thread for the archives. As it was just sent to the imports@ list, but not dev@ list,<br><br>It attempts to solve the ideas that jaak noted below. <br><a href="http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005544.html">http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005544.html</a><br>
<br>(I was going to respond last week on this thread) ... with 'OpenImportsMap' . Perhaps the wiki can be expanded, i added my notes tot he talk page of it, and will attempt to incorporate the ideas from this thread also.<br>
<a href="http://wiki.openstreetmap.org/wiki/Importing_Government_Data">http://wiki.openstreetmap.org/wiki/Importing_Government_Data</a><br><br>It was in response to: <br>from steveC original post about Announce: openOS (Ordinance survey releasing data)<br>
<a href="http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005543.html">http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005543.html</a><br>
<br>Cheers,<br>Sam<br><br><div class="gmail_quote">On Sat, Mar 27, 2010 at 10:28 AM, Jaak Laineste <span dir="ltr"><<a href="mailto:jaak@nutiteq.com">jaak@nutiteq.com</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;">
<div class="im">> > some kind of priority over the others. Like possibility to<br>
> > lock/protect some parts of the data. It could be done in several levels:<br>
><br>
> > 1) my inserted data (tag, node, relation, way - any of them) can be<br>
> > defined as private, nobody else can not even see it.<br>
> > 2) my data is protected - you can see, but not modify<br>
> > 3) my data has group privacy/protection under my control: I can give<br>
> > view/ modify / delete permissions to specific users/groups<br>
><br>
> These three are, in my opinion, not compatible with the spirit of OSM.<br>
> If you want your own data, store it somewhere else ;-)<br>
<br>
</div>There could be quite good reasons to protect some of the data at least<br>
temporarily. Very technical reason: to avoid accidental deletion of nodes<br>
during bulk import (which takes days sometimes). Well, maybe bulk import in<br>
general is not really fully compatible the spirit of OSM after all. What is<br>
more important purpose of OSM: is it the biggest outdoor mapping capturing<br>
tool, or does it want to be the world largest and best community-created map<br>
database? If outdoor mapping is the primary aim, then right, the corporate<br>
imports are not needed, maybe even need to be banned. If the database<br>
contents and quality the is target, then the imports and database links must<br>
be as plentifyl, good and made contributor friendly as possible. My implicit<br>
assumption was that OSM wants to be as good database as possible, but I<br>
could also have totally missed the point of OSM. Anyway, my preference is<br>
that OSM aim is to be as good database as possible, and outdoor mapping is<br>
just one of the great ways to create and update data.<br>
<br>
There are good datasources (from public sector) who have 80% of their data<br>
open and in principle well compatible with OSM, but 20% of them should have<br>
some protection. Technically splitting the data could be so complicated that<br>
their only option now is not to share anything, i.e. just not to use OSM.<br>
<br>
I have a particular example: a friend just called me, and he is in board of<br>
national assiocation of museums. They have and maintain kind of official<br>
database of all museums in the country. They wanted to have them on web map,<br>
and I suggested to use OpenStreetMap, and not only as background image, but<br>
also insert their data as points to the OSM. This bought me several<br>
questions:<br>
- is the only legitimate way to have one-time bulk import, and then just<br>
hope that community will only improve it? Or could they have a bit more<br>
special control (external IDs, notifications, soft locking of some tags etc)<br>
over the data, at least to make their data maintenance easier. To enable<br>
more automatic sync with their in-house data maintenance systems and<br>
procedures.<br>
- Today the only way for them is anyway double maintenance: they maintain<br>
their internal/primary database, and maybe they care to copy their<br>
day-to-day updates manually also to OSM. Is there a way to make maintenance<br>
of only their specific data in OSM easy? One complicated solution would be<br>
to use JOSM+XAPI to make extracts based their own tags. But this is risky,<br>
you can easily create reduntant data if you do not see the data around each<br>
node. Also I cannot imagine this type of "once a month" users actually using<br>
hard-core mapping beasts like JOSM, maximum what they could care to learn<br>
would be somewhere in Potlatch (but without the roads!) / Mapzen level.<br>
<font color="#888888"><br>
<br>
Jaak<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Imports mailing list<br>
<a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
</div></div></blockquote></div><br><div style="visibility: hidden; display: inline;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup { position:absolute; z-index:9999; padding: 0px 0px; margin-left: 0px; margin-top: 0px; width: 240px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 13px;}</style><input id="gwProxy" type="hidden"><input onclick="jsCall();" id="jsProxy" type="hidden"><div id="refHTML">
</div>