[OSM-legal-talk] Interesting use case of combining OSM with proprietary data

Christoph Hormann 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
> pixel."
> 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 
without share-alike.

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.

Christoph Hormann

More information about the legal-talk mailing list