Hi, Jaak Laineste wrote:
What about following approach: a) ban external source imports to the main database b) create new separate solution (layer, server, API, whatever fits) for all the imports.
I think that is the way forward. If your data has special requirements, then put it in a special database, not in OSM. Do not abuse OSM as a vehicle for non-crowdsourced (or even non-crowdsourcable) data.
What would be special about this imported data layer solution: - update permission system, someone can be maintainer of the data - free to copy data from import->main database
How would this then be different from an import to the main database?
- planet.osm it would have the data in special section.
No, planet.osm would not even know about that data. I imagine this to be something like in the brave new world of git: You can run a rendering server and you can instruct your osm2pgsql to pull data from the OSM planet repository, and from Alan's "US Borders" repository, and from someone else's "International Maritime Lights" database, etc.etc.; an expert editor could even allow you to do the same, pull data from different sources, even edit all of it if you have the proper credentials and upload back to all the different sources.
There is of course still a case for many things to reside in OSM - e.g. it would not make much sense to have one database with major roads and one completely separate database with minor roads, as it would always be a terrible pain to extract from them a working, routable network. But especially where we're talking non-physical things like boundaries, such a de-coupling makes a lot of sense to me.
Bye Frederik -- Frederik Ramm ## eMail [email protected] ## N49°00'09" E008°23'33" _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
