[OSM-legal-talk] Interesting use case of combining OSM with proprietary data
kathleen.lu at mapbox.com
Fri Jan 12 22:40:45 UTC 2018
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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the legal-talk