[Talk-us] Unintentional improvements in OSM data influencing / improving other databases

[Joseph Eisenberg]

RE: "Many government and agency data sources are in conflict with each
other over the same information; OSM can serve to provide "resolved"
versions that are confirmed with ground observation where required."

Similar thoughts have been expressed previously in this thread.

But if we are talking about legal parcel boundaries or legal protected area
boundaries, or administrative limits, then it's not at all possible for
OpenStreetMap users to resolve these conflicts in our database alone.

What needs to happen is bringing this information back to the local
government and asking them to correct the data and provide an
authoritative, public-domain source for everyone to use.

It's no good if OpenStreetMap has a more "accurate" boundary line which
follows a physical feature like a ridgeline, if the legal definition is
different. Determining this might require lawyers getting involved.

Now certainly OpenStreetMap data, which can include features like
ridgelines, waterways, roads and paths, which are often used to determine
historic land ownership boundaries, can be useful in determining if
existing databases are accurate and precise. But unless those outside
databases are corrected, our data will be inaccurate as well, when it comes
to legal issues like boundaries.

- Joseph Eisenberg

On Wed, Sep 2, 2020 at 11:39 AM Bradley White <theangrytomato at gmail.com>
wrote:

> I echo this sentiment exactly as having taken place in California and in
>> my experiences with OSM.  This is most certainly a longer-term endeavor
>> (over several, even many years), but improvements in alignments between
>> data components which have been entered into OSM from my County GIS,
>> GreenInfo.org's publishing its "CPAD" (California Protected Area Database,
>> published semi-annually, see our wiki) and other sources HAVE INDEED
>> resulted in data improvements:  OSM influences CPAD, resulting in data
>> improvements, CPAD influenced County GIS data, resulting in data
>> improvements, later versions of these (County GIS and CPAD) data influenced
>> OSM all over again, resulting in data improvements...and upward, upward and
>> upward the spiral of more accurate, better-aligning data goes:  both
>> private and public.  OSM gets the results, so do others.  Win-win.  Taking
>> OSM out of the equation by asserting "these data don't belong in OSM" stops
>> this improvement pipeline (wholly unintentional on my part, but certainly
>> noticed) in its tracks.  (Yes, some data belong in OSM, some don't).
>
>
> I'm in strong agreement here. OSM provides a unique platform to synthesize
> multiple data sources in combination with field observation to produce
> something potentially better than any of these single sources are on their
> own. Trying to produce an accurate and detailed map of the entire US
> strictly off of field observation and satellite imagery is simply
> infesible, especially in remote, unpopulated areas. Many government and
> agency data sources are in conflict with each other over the same
> information; OSM can serve to provide "resolved" versions that are
> confirmed with ground observation where required.
>
> I agree that we shouldn't be importing parcel data wholesale, as-is. But,
> if real-life accuracy is important, the fact that much of the information
> we are trying to add in OSM (protected areas, land use, access
> restrictions) is differentiated along parcel boundaries is simply
> unavoidable to me. If this information is in the public domain and
> generally corroborates what is on the ground, so long as the data is worked
> through manually to confirm accuracy, I don't see the problem with using
> parcel information as a piece of the "puzzle" in producing an accurate and
> informative map.
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20200902/dc4a4f9c/attachment.htm>