[OSM-legal-talk] Interesting use case of combining OSM with proprietary data

Christoph Hormann chris_hormann at gmx.de
Sat Jan 13 09:14:40 UTC 2018

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 

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

More information about the legal-talk mailing list