[OSM-legal-talk] Updated geocoding community guideline proposal

[Simon Poole]

Am 03.11.2014 um 00:45 schrieb Alex Barth:
> I have two questions on the Collective DB alternative:
> 
>> The derivative database consists of the data that has been used as the
> input data for the geocoding process, as well as the data that has been
> gained from OpenStreetMap in the process. Any additional data that may
> be linked to this data, even sitting in the same logical database table,
> is however not considered to be part of the derivative database (instead
> it forms a collective database together with the derivative database)
> and therefore, does not have to be shared under the ODbL.
> 
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Geocoding_-_Guideline#.22Collective_Database.22_alternative
> 
> 1. Why is the input data part of the Derivative Database?

There is an underlying assumption that the input data will match, in the
best case exactly, an object in the OSM dataset, and that you are
extracting further information about it (aka its geographic location)
from the OSM data.

Note that in this model we are treating the input data as a key in to
the geocoded dataset.

Treating the geocoded results plus input data as a derivative DB
sidesteps various issues. They have their roots in, on the one hand, the
most popular OSM based geocoder not just returning a pair of coordinates
and, on the other hand, us having no control over how geocoding is
technically implemented. It further makes clear if that you are using
more attributes to improve the geocoding that they are subject to the
same terms.

> 2. This language is not explicit about Geocoding Results from other
> databases that are stored in the same database. Would they be part of
> the Derivative Database?

I believe that is a not an issue as formulated. You would need a clear
way of keeping the data separate. For lack of a better example: two
tables: addresses geocoded with OSM, addresses geocoded with here, but
IMHO labelling the geocoding source could be considered enough (given
that you may want to provide dynamically displayed attribution you would
likely want to do this in any case).

The real underlying issue is the fallback issue: can a set of negative
results (no geocoding result from OSM) form a derivative database? On
the fly it is IMHO a non-issue, however in the bulk/permament geocoding
scenario it is.

Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20150220/22bc4a4b/attachment.sig>