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

[Christoph Hormann]

On Saturday 13 January 2018, Paul Norman wrote:
>
> Has anyone requested the derivative database their produced work is
> based on? It'd give us their interpretation.

As said i have contacted the author (primarily regarding attribution - 
which he promised to improve - and has partly already done).  I also 
mentioned the share-alike issue - but the author thinks this is fine as 
it is and i am not really in a position to claim it is not.  He also 
said he cannot provide the Google roads data itself since the Google 
terms do not allow this (obviously).

Part of the problem is also they are using Google Earth Engine - which i 
am not familiar with and which probably makes many of the data 
processing steps fairly opaque so the authors might not be fully aware 
of what actually happens in detail 'under the hood'.

I suppose if you pressure the authors into providing more intermediate 
data you might get separate raster maps for the OSM roads and the 
Google roads.

-- 
Christoph Hormann
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Paul Norman]

On 1/11/2018 7:30 AM, Christoph Hormann wrote:

My interpretation of the ODbL here is that this is a share-alike case
that would require the combined data sources to be made available.  But
you could probably also look at it differently.  I would like to hear
opinions on this.  In particular if you think that is legally possible
without share alike how this interpretation looks like.


Has anyone requested the derivative database their produced work is 
based on? It'd give us their interpretation.


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Christoph Hormann]

On Saturday 13 January 2018, Kathleen Lu wrote:
> Your example doesn't work. Even if you could render
> "distance-to-water"
>
> this way, you wouldn't get a set proprietary data based lakes + OSM
> lakes, you would get a visualization of one massive complicated body
> of water that included all oceans, rivers, streams, etc. (at the
> database level, it would still be a bunch of data values, not a big
> polygon, plus the OSM polygons). This doesn't sound minor to me at
> all, as that's a lot of data to process (leaving aside that you'd
> have to have a distance-to-water API to pull from, which would not be
> easy to get).

This is stuff i do for a living so believe me if i say - if that's all 
that is standing between you and combining OSM data with proprietary 
data sets without share-alike that is a piece of cake.

Yes, labels and other non-geometry information would be a problem - but 
there is plenty of geometry-only data in OSM and geometry only 
applications (like the example we are discussing) for which this 
applies.

To summarize the results and be clear - also for my own business 
purposes - could i get clarification for the LWG that "primary feature" 
in the collective database guideline, in line with Kathleen's 
interpretation, can be based on a technical distinction, i.e. two 
features with the same meaning (both roads or both lakes) are 
considered different primary features depending on if they are 
described in explicit form (like linestring or polygon) or implicit 
form (like distance function)?

-- 
Christoph Hormann
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Kathleen Lu]

>
> 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).
>
> What I'm saying is that road geometry is a different type of feature than
"distance-to-road" data. "Distance-to-road" would give you the distance to
the nearest road, it doesn't give you each separate road, and you couldn't
substitute that value for a real road network.


>
> 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.
>
> Your example doesn't work. Even if you could render "distance-to-water"
this way, you wouldn't get a set proprietary data based lakes + OSM lakes,
you would get a visualization of one massive complicated body of water that
included all oceans, rivers, streams, etc. (at the database level, it would
still be a bunch of data values, not a big polygon, plus the OSM polygons).
This doesn't sound minor to me at all, as that's a lot of data to process
(leaving aside that you'd have to have a distance-to-water API to pull
from, which would not be easy to get).


> 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.
>
> I disagree with the implications. Even stretching such a scenario to the
extremes as you describe above, I do not see a practical result that hurts
OSM. The visualization you described sounds really pointless. Sharealike or
not, why would someone go through this type of contortion to get an
approximate map rendering of water, with no labels for the proprietary
water areas? Such a map would look terrible.
If we look at actual use, the researchers added the assigned speed values
to calculate friction, which is useful for their research. The end result
does not in anyway substitute for an OSM road network, which is what we
should really be concerned with. I do not believe you'd presented a
realistic hypothetical that would really change OSM use and thus present a
true risk.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Christoph Hormann]

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 
rendering.

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
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Kathleen Lu]

They are using OSM road data and Google road data to generate what they
> call a "friction surface" which is essentially a raster map indicating
> how fast you can move at every point of the map - faster on roads,
> slower elsewhere depending on relief and landcover.  This friction map
> you can download on:
>
>
> https://map.ox.ac.uk/wp-content/uploads/accessibility/friction_surface_2015_v1.0.zip
>
> You can see in that map that they are using OSM road data and that they
> are also using data that is not in OSM.  Based on this friction map
> they are doing the accessability calculations.
>
> Of course it is possible that the OSM road data and the Google road data
> is available in different forms originally - as you write the wording
> indicates they have proximity information on the Google roads and not
> the actual geometry.  But they merge it to generate the friction map,
> for that it does not matter in what form the roads data exists, and i
> don't really see how you can argue this creates a collective database
> and not a derivative database - because if that is not a derivative
> database (combining two incomplete data sets to create a more complete
> data set to use) what is?
>
> 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:

   - the non-OSM data adds a particular type of geometry or data for a
   primary feature that was not already present within a regional cut, and the
   added feature data includes no OSM data; or


   - a non-OSM database replaces or adds a property of a primary feature,
   and uses either all OSM data or no OSM data for that property of that
   primary feature within the same regional cut (e.g., the URL property of the
   amenity=cafe primary feature is replaced by reference, using either all OSM
   data or no OSM data for the replacement URLs);

They state that datasets may be combined as long as there is no mixing of
an OSM data source with a non-OSM data source for a given
datatype/property. (It doesn't matter if the datasets can be thought of as
referencing each other because "the non-OSM and OSM datasets do not
reference each other" is only one of four examples the Guideline provides
of collective database circumstances.)

The Google distance-to-roads are not mixed with a OSM datatype. It's not
possible, as OSM doesn't have a distance-to-road datatype, and the Google
distance-to-road calculation is a calculation of the distance to the
nearest Google road, not the nearest OSM road.

The "speed to cross" value is also not an OSM data type. It is an entirely
new property that the researchers assigned to OSM road features based on
their own views of how "fast" a feature is. Whether the researchers also
assigned "speed to cross" properties to features from other datasets is
irrelevant, as those values didn't come from OSM.

The OSM road network + Google distance-to-road data + new assigned property
type "speed to cross" is the overall collective database the researchers
put together. They then performed calculations and analysis on this
database, including assigning a "friction" value to each pixel of a raster
map. That map I agree is a Produced Work, and it is a Produce Work built
from a Collective Database.
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Christoph Hormann]

On Friday 12 January 2018, Rory McCann wrote:
> As near as I can see, the only data they are distributing (publicly)
> is the 2 GeoTIFF files in the "map.ox.ac.uk" page. The question is:
> Is a GeoTIFF file created like this from OSM data which has been
> mixed with other data, a Produced Work, or a Derived Database?

No, that is not significant - see 4.4c of the ODbL:

Derivative Databases and Produced Works. A Derivative Database is
Publicly Used and so must comply with Section 4.4. if a Produced Work
created from the Derivative Database is Publicly Used.

So the question is only if there is a derivative database involved in 
the production of the GeoTIFF, not if the GeoTIFF itself is a 
derivative database.  My view would be that the aggregation of data 
from the OSM database and the Google roads data when creating the 
raster map constitutes a derivative database even if the two data sets 
are not physically merged into a common table because this happens on 
the fly.  See:

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline

"Technically a reference between non-OSM and OSM data can be by a 
database key or any other method of identifying a specific OSM or 
non-OSM element that may be used with a database join."

So if for the purpose of creating the raster map you query all OSM roads 
within each pixel, determine which Google roads are within a pixel size 
distance of the pixel center (or something like that) and calculate the 
minimum friction value of those this is technically "a reference 
between non-OSM and OSM data" IMO.

> *But* (possibly stupid question time) I'm reading the ODbL and it
> (Sec 4.6) only requires that you make the derived database available
> *or* the original scripts, and original contents. By releasing the
> GeoTiff file(s) they've fulfilled Sec 4.6(a), no?

No, the GeoTIFF is quite clearly a produced work as per the ODbL:

"a work (such as an image, audiovisual material, text,
or sounds) resulting from using the whole or a Substantial part of the
Contents (via a search or other query) from this Database, a Derivative
Database, or this Database as part of a Collective Database."

And the produced work guideline:

https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline

"The published result of your project is either a Produced Worked or a 
Derivative Database within the meaning of the ODbL. If the published 
result of your project is intended for the extraction of the original 
data, then it is a database and not a Produced Work."


One point you could argue is that you could produce the friction map by 
separately rasterizing the OSM and Google roads data and then merge 
what is already a produced work with a minimum operator on the two 
raster files.  Since the raster is already a produced work you could 
argue that the ODbL does not apply then.  But on the other hand you 
could argue (as you already did in your mail) that once you use a 
produced work in a database-like fashion it becomes a derivative 
database again - the same way as if you trace features from a rendered 
OSM map.

-- 
Christoph Hormann
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Rory McCann]

As near as I can see, the only data they are distributing (publicly) is
the 2 GeoTIFF files in the "map.ox.ac.uk" page. The question is: Is a
GeoTIFF file created like this from OSM data which has been mixed with
other data, a Produced Work, or a Derived Database?

In support of "Produced Work", GeoTIFF is (on paper) *literally* an
image file format. Images (AFAIK) based on OSM data have always been
viewed as produced works, so this shouldn't be different.

In support of "Derived Database", these GeoTIFFs do feel like a
database. The files don't have any artistic styling, they are basically
a 2D arrangement of numbers, you can import it into a geo database (like
PostGIS), you can query the file for "what's the value at this point?",
it's only useful if you decide to style it as you decide. The project
itself has used one of these GeoTIFFs as input data for another process,
etc.

IMO these GeoTIFF files are (overwhelmingly) more like a database than
an image.

*But* (possibly stupid question time) I'm reading the ODbL and it (Sec
4.6) only requires that you make the derived database available *or* the
original scripts, and original contents. By releasing the GeoTiff
file(s) they've fulfilled Sec 4.6(a), no? Isn't that enough for the 
share-alike aspect? And they aren't required to release all the other

original (Google) data?

Obviously if it's a Derived Database, they need to release it under the
ODbL licence (or similar). The page says CC-BY and that isn't right at all.

On 11/01/18 16:30, Christoph Hormann wrote:


Today i stumbled across this:

https://map.ox.ac.uk/research-project/accessibility_to_cities/
http://dx.doi.org/doi:10.1038/nature25181
https://explorer.earthengine.google.com/#detail/Oxford%2FMAP%2Faccessibility_to_cities_2015_v1_0

Apart from partly insufficient attribution (which i already contacted
the author about) this is an interesting case example of combining OSM
with proprietary data sets i would like to hear some opinions about.

What is done here is combining road information (and some other data)
from OSM and proprietary data sources (Google) into a raster map (made
available as 'friction surface' under the first link above) and doing
further processing, analysis and map rendering based on that and
publishing the result.

My interpretation of the ODbL here is that this is a share-alike case
that would require the combined data sources to be made available.  But
you could probably also look at it differently.  I would like to hear
opinions on this.  In particular if you think that is legally possible
without share alike how this interpretation looks like.





___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Christoph Hormann]

On Thursday 11 January 2018, Kathleen Lu wrote:
>
> I don't have access to the locked Nature article, but the description
> from the first link suggests that they are using a derivative
> statistic calculated from the Google road network instead of the
> network itself: "The game-changing improvement underpinning this work
> is the first-ever, global-scale synthesis of two leading roads
> datasets – Open Street Map  (OSM)
> data and distance-to-roads data derived from the Google roads
> database
> ..."
> "Distance-to-roads data" sounds like a data type that is not in OSM
> (they might have been able to calculate it from OSM, but evidently
> chose not to), which would be an example of non-sharealike use under
> the Collective Database Guideline:
>
> [...]

Then you have probably misunderstood what they are doing.

They are using OSM road data and Google road data to generate what they 
call a "friction surface" which is essentially a raster map indicating 
how fast you can move at every point of the map - faster on roads, 
slower elsewhere depending on relief and landcover.  This friction map 
you can download on:

https://map.ox.ac.uk/wp-content/uploads/accessibility/friction_surface_2015_v1.0.zip

You can see in that map that they are using OSM road data and that they 
are also using data that is not in OSM.  Based on this friction map 
they are doing the accessability calculations.

Of course it is possible that the OSM road data and the Google road data 
is available in different forms originally - as you write the wording 
indicates they have proximity information on the Google roads and not 
the actual geometry.  But they merge it to generate the friction map, 
for that it does not matter in what form the roads data exists, and i 
don't really see how you can argue this creates a collective database 
and not a derivative database - because if that is not a derivative 
database (combining two incomplete data sets to create a more complete 
data set to use) what is?

> (And frankly, I can't see Google cooperating with this project if
> there were sharealike implications for their proprietary data, so I
> have to assume that their lawyers vetted the use and confirmed they
> datasets were used together as a Collective Database.)

I have considered that but since Google does not carry any legal 
responsibility in that this does not seem like a valid argument - on 
the contrary:  If they have doubt about the legality of this kind of 
data use this is the perfect trial balloon to test how far you can go.  
And if Oxford University gets screwed over this that is not their 
problem.  If not and this kind of data combination becomes widely 
accepted this would OTOH open the door for a lot of applications that 
would depend on circumventing share-alike.

-- 
Christoph Hormann
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Kathleen Lu]

Hi Christoph,

What is done here is combining road information (and some other data)
> from OSM and proprietary data sources (Google) into a raster map (made
> available as 'friction surface' under the first link above) and doing
> further processing, analysis and map rendering based on that and
> publishing the result.
>

I don't have access to the locked Nature article, but the description from
the first link suggests that they are using a derivative statistic
calculated from the Google road network instead of the network itself:
"The game-changing improvement underpinning this work is the first-ever,
global-scale synthesis of two leading roads datasets – Open Street Map
 (OSM) data and distance-to-roads data
derived from the Google roads database
..."
"Distance-to-roads data" sounds like a data type that is not in OSM (they
might have been able to calculate it from OSM, but evidently chose not to),
which would be an example of non-sharealike use under the Collective
Database Guideline:

   - the non-OSM data adds a particular type of geometry or data for a
   primary feature that was not already present within a regional cut, and the
   added feature data includes no OSM data

The map itself and the visualizations on top of it would appear to be
Produced Works, so also not subject to sharealike.

(And frankly, I can't see Google cooperating with this project if there
were sharealike implications for their proprietary data, so I have to
assume that their lawyers vetted the use and confirmed they datasets were
used together as a Collective Database.)

-Kathleen
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

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

[Christoph Hormann]

Today i stumbled across this:

https://map.ox.ac.uk/research-project/accessibility_to_cities/
http://dx.doi.org/doi:10.1038/nature25181
https://explorer.earthengine.google.com/#detail/Oxford%2FMAP%2Faccessibility_to_cities_2015_v1_0

Apart from partly insufficient attribution (which i already contacted 
the author about) this is an interesting case example of combining OSM 
with proprietary data sets i would like to hear some opinions about.

What is done here is combining road information (and some other data) 
from OSM and proprietary data sources (Google) into a raster map (made 
available as 'friction surface' under the first link above) and doing 
further processing, analysis and map rendering based on that and 
publishing the result.

My interpretation of the ODbL here is that this is a share-alike case 
that would require the combined data sources to be made available.  But 
you could probably also look at it differently.  I would like to hear 
opinions on this.  In particular if you think that is legally possible 
without share alike how this interpretation looks like.

-- 
Christoph Hormann
http://www.imagico.de/

___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk