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
