[OSM-legal-talk] using osm data and other sources in a project
lists at sunsetutopia.com
Mon Aug 22 06:14:43 BST 2011
On 19 August 2011 18:30, Jukka Rahkonen <jukka.rahkonen at latuviitta.fi>wrote:
> James Livingston <lists at ...> writes:
> > If you can't produce separate tiles, because rendering requires
> > accessing both databases at once, then you essentially have
> > combined the two databases together into a new one and are then
> > rendering based on that. So would assume in this case you'd have
> > to distribute the combined database (or the non-OSM one and
> > tell people to put them together as the "modification").-- James
> The blue sea is coming from one database, borders from another and red OSM
> motorways from a third. All with one request and end user cannot separate
> sources from the png image. Let's assume that sea and border data are not
> allowed be added to OSM or delivered as ODbL. Should we tell WMS users that
> are not allowed to do the WMS request as &LAYERS=sea,borders,osm_viivat but
> must make three separate requests and combine the result
I probably didn't make it obvious enough in my post, but the word "can" in
"If you can produce separate tiles" is very important to my point.
I believe that producing a sea tile from one set of data, a borders tile
from another set of data, and the motorsways tile from a third set of data,
and then combining them together before sending them to the user would be
fine. In this case, the motorway tile would be a Produced Work based on OSM
data, so you can choose the license to be one that allows you to combine it
with the other tiles. I think that simply overlaying the data should be fine
since they are independent of the other data sources
On the other hand, if you got road data from OSM, POI data from somewhere
else, and then rendered them with an algorithm that hid POIs too close to
the road (so the road wasn't hidden), then that would cause a Derivative
Database to be created. The Produced Work would depend on both datasources
to produce, so I think you'd need to distribute the derivative database
and/or additional data.
Going back to the original poster:
> For the roads, we will update the attributes for additional info the org
> (i.e. admin types, etc). For the river, we will also update
> attributes (i. e. stream orders, etc.).
> For the other internal data, this will be on a separate db/layer but will
> integrated into the osm layers for simple map-based monitoring
It sounds like they need to mix the two datasources before creating a
Produced Work (rendering), which to me seems like it would create a
derivative database - although it may just be a temporary one in the
in-memory data structures of the renderer. In your example, you can mix it
after creating the Produced Work(s), so it would be okay.
Obviously that's my own opinion, IANAL, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the legal-talk