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_______________________________________________
Imports mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/imports
