[OSM-talk] immutable=yes Fwd: DEC Lands

Jukka Rahkonen jukka.rahkonen at mmmtike.fi
Mon Mar 16 17:36:52 GMT 2009


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.







More information about the talk mailing list