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