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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/legal-talk
