Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data
> > 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
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
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
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
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
