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

[Jaak Laineste]

On 25.04.2011, at 5:17, Alan Mintz wrote:

> At 2011-04-24 15:36, Richard Fairhurst wrote:
>> Jan Iven wrote:
>>> As such, is there some agreed way for a large-scale import to pass
>>> the message to editors such as Potlatch that they need not bother
>>> editing these features? (this would allow me to go off and pester
>>> these editors to actually honour such an attribute). Of course, the
>>> editor could chose not to honour this (i.e. JOSM when
>>> importing/improving some CORINE areas), but at least this would then
>>> be intentional.
>> Potlatch is not a "simple" editor. You can, and many people do, use it as your sole OSM editor. I will categorily not permit any function to be added to it that prevents certain items from being edited.
> 
> How about not "prevent", but at least warn the user and ask them to confirm when editing such features? The admin borders are a perfect example where it would take some real research to manually edit/correct them. If someone wants to do that work, great, but they should be able to then ask others not to edit unless they know what they are doing. It doesn't have to be enforced, but we can certainly ask people to comply, right?
> 
> Another good example is benchmarks/survey points, some of which I've been adding. The benchmark itself is at a specific, highly accurate position (lat/lon), and should not be moved unless the benchmark itself is re-surveyed. A control point nearby (used to identify imagery offset), based on a certain imagery set, should not be moved either.
> 
> How about confirm_edit=yes | "Some message to be displayed to editing user"? A value of "yes" displays a default message, while other values let the user explain the reason why it might not be correct to edit it.

Any good mapping database should be able to combine original data with existing sources in reasonable way. OSM is very biased to the original surveys, and I would say it is not optimized at all to handle properly external sources which need special handling for various reasons. Currently the only way is to ignore any special requirements, like editing restrictions (like warnings as you suggest), different licenses/attributions, bulk updatability (foreign keys) etc. Also it looses any link with original data, which is no good for different reasons.

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.

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
- planet.osm it would have the data in special section. In mapnik db it would be just as normal data.

 Actually in principle it would not be too strange, as it would be somewhat similar to existing GPS tracks database solution. Technical API itself can be similar to current one, with minor modifications, so also editing tools require minimum updates.

I know it would not be easy, a lot of special cases would come (e.g. ownership transfer when someone takes imported object, copies and updates it in main db, how to handle duplicates, what do do with already done imports etc). Perhaps an idea for API 0.7

Jaak