[Talk-us] Anyone ever talked about adding more Land Ownership data to OSM?

[Greg Troxel]

Toby Murray <toby.murray at gmail.com> writes:

> I think it would be great to make more tools support more external
> data sets as opposed to dumping *everything* into OSM. You want county
> borders on your garmin? Check a box while creating the file and mkgmap
> downloads the most recent county borders from some source that isn't
> OSM and includes them. Now, building this functionality into every
> tool that uses OSM data may not be practical. But I can definitely see
> a place for a parallel project that hosts all such boundary data
> (maybe even parcel data) from official sources in a common format and
> can be easily mixed with OSM data before being fed to existing tools.

To me, this hints at why the characterization of boundary data as not
subject to improvement by OSM is off.   Producing a file of all boundary
data is still a large amount of effort best done by the cooperation of
many people, each looking into local issues.  There is no single source
that anyone can point to.  In Massachusetts, TIGER county data has been
replaced with much more accurate town boundary data, and that was an
improvement to OSM done by an individual mapper.  Choosing the source
data is still an act of local judgement, and having a curated set of
data is very valuable.

If we take the "separate database" to its logical conclusion, while
keeping the notion of data stewardship, we'd end up with a database that
had pretty much the editing functions of OSM, maintained by many local
people.  If we don't have functionality regressions, then the default
render would use this data, and all processing tools would be able to
use.  So in the end we would have simply added layers to OSM (or a
single boundary layer).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20130108/6ecbe722/attachment.pgp>