[Imports] "readonly" tag for imported data (ask "simple" editors to not modify)?

[Jaak Laineste]

On 25.04.2011, at 20:16, Michael Leibowitz wrote:

> On 04/25/2011 07:57 AM, Serge Wroclawski wrote:
>>> 
>> I've been thinking that it might make sense for OSM to implement a
>> secondary databases set internally- a place where people can upload
>> datasets which might be appropriate for OSM, then use things like the
>> vector layer in PL2 to trace over them where it makes sense.
> 
> So, it's OK to trace over an administrative boundary displayed in PL2 and have that as part of OSM, but inserting it via API is not OK?  Is that correct?  What's the rationale?
> 

 Well, the result would be the same: you would have totally disintegrated copy of the data. The question is how to avoid any copy/import, not how to do it. Any later update of the administrative data would be terrible manual work (more than original one), as you will have to merge all the community edits and official edits. So in reality nobody will do the later updates, eventually OSM will have pile of more and outdated data, what community cannot maintain and it will be more and more crappy due to it. This is the issue what "readonly" tag suggestion tries to achieve, but distributed architecture would solve it in much better and systematic way.

 OSM DB today is like SVN - you must have  central server with all the changesets. Now in 2010s it should be (a little bit) like GIT:
1) a protocol (OSM API with meta-extensions) for changeset transfers
2) open sourced software stack which enables to set up own servers easily
3) open sourced client software packages (JOSM)
4) current data would be just one of the repositories: say api.openstreetmap.org ("the github"). Import-fans could set up own "shared imports server" with manually merged (but disintegrated) data which has no hope for later mass-updates. And each major import candidate should consider to set up own server, for automatic updates it should be mandatory.
5) single central meta-api/directory/discovery server which responds with lists of URL-s to bbox queries. It is not expected that each of the imports is suitable for any purpose, there might be even several "competing" datasets for same area and objects.

 Why we want to do imports? Not  because we want to mess up the nice OSM hand-crafted database, but because there is currently no other way to have the world mapped with much more information, faster and with higher quality. 

 I'd be ready to contribute some days to try to undo my own mass-imports and put it to separate server; if only there was one.

BR
Jaak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20110425/0db2c00e/attachment-0001.html>