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