[OSM-legal-talk] Interesting use case of combining OSM with proprietary data
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
> 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)?
More information about the legal-talk