On Mon, 2011-04-25 at 00:55 -0700, Jaak Laineste wrote: > 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
Would the imported data be accessible through the same API as the survey based data? I would hope so, as things such as administrative boundaries are actually useful. It would be a shame if I could find all the benches near me, but not what county I am in via API. Cheers -- Michael Leibowitz <[email protected]> _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
