Toby Murray <[email protected]> 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).
pgpp8tBlc8Z0c.pgp
Description: PGP signature
_______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
