Ted Mielczarek <ted.mielczarek <at> gmail.com> writes: > > On Sat, Mar 14, 2009 at 7:33 AM, Jukka Rahkonen wrote: > Why not to store this kind of datasets as own layers in the database? DEC > data > could be on its own, non-editable layer, but if there's something that people > would like to edit those features could be copied or lifted to anothet, OSM > layer. That would make DEC updates easier as well, they would just update the > DEC layer. The same approach would suit other data of similar nature as well, > like TIGER or cadastrial data. > > > If you can't edit it it shouldn't be in the OSM db. It's easy enough to set up your own map render with any external data you want.-Ted
Hi, I meant non-editable layer, not non-editable data. In addition to user contributions OSM is already a massive collection of bulk data imports and more is to come. Big external datasets are usually also maintained by some organisations and updates are available every now and then. It should be as easy as possible to update the imported data without a need to do the whole import again. And updates are necessary, otherwise the data start soon to rotten. Workflow might be like: - Import of external data, each imported feature gets an unique ID. - If imported feature needs to be edited, it will be lifted on another layer (main OSM database perhaps) with imported ID as a key. - For rendering and data exports the edited feature, the OSM version, would be used. - When external data is updated those features which have never been lifted into OSM layer can be updated automatically. - If some feature has been lifted to OSM layer it would get a note "New version of this feature has received from the original data provider. Please check which version is correct for OSM". TIGER data is actually not a very good example because it must be noded together with native OSM data in order to make routing to work. That makes it hard to update automatically. Cadastrial data and various POI collections are more what I was thinking about. _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
