[OSM-legal-talk] Interesting use case of combining OSM with proprietary data
chris_hormann at gmx.de
Sat Jan 13 00:00:38 UTC 2018
On Friday 12 January 2018, Kathleen Lu wrote:
> Your analysis does not follow.
> The researcher's description says: "These datasets were each
> allocated a speed or speeds of travel in terms of time to cross each
> pixel of that type. The datasets were then combined to produce a
> 'friction surface'; a map where every pixel is allocated a nominal
> overall speed of travel based on the types occurring within that
> Thus, the "friction map" is calculated from first an assignment of a
> "speed to cross" property value to each road, railway, etc. This was
> a property value one added by the researchers, not one already in
> OSM. Thus, these principles from the collective database apply:
My argument has nothing to do with the property (which could for the
purpose of this simply be a constant value for all roads, i.e. a
property containing no information at all).
My argument is about the geometry information. The friction map
combines road geometries from OSM and Google road geometry information.
I see no way it can be argued that this combination of road geometry
data which is rendered into the friction map is a collective database.
None of the four criteria of the collective database guideline is met
(unless of course you postulate that OSM roads are a different type of
feature than Google roads).
You can also look at it from a different perspective: If the mentioned
use is compatible with the ODbL without share alike that would create a
completely fool proof way of circumventing share-alike in map
Example: You want to render a map with lakes supplementing the
incomplete lake data from OSM with proprietary data from elsewhere. So
what you do is:
* you take the lake geometries from OSM (equivalent to the OSM roads)
* you create a distance-to-water function/API for you proprietary lake
dataset (equivalent to the Google distance-to-road API)
* you render both the OSM (based on the polygon geometries) and the
proprietary data based lakes (based on the distance function) into your
map (equivalent to the rendering of the friction map)
* you enjoy your map showing lakes from both OSM and proprietary data
Yes, depending on how you want to style your lakes doing so based on a
distance function can be challenging - but that is just a minor hurdle.
Note from a business perspective as a data user i would not really mind
if the above scenario was acceptable but as said it would practically
mean the end of share-alike for map rendering applications - and that
is likely not what the mappers who voted to adopt the ODbL had in mind.
More information about the legal-talk