Am 10.03.2015 um 02:10 schrieb Alex Barth: > > On Thu, Feb 19, 2015 at 11:52 PM, Simon Poole <si...@poole.ch > <mailto:si...@poole.ch>> wrote: > > > > 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. > > > Not sure I follow here. The "geocoded results plus input data" in and > itself would be in the most common cases not Substantial even by OSM's > very aggressive definition of what's Substantial (< 100 features OTOH).
A non-Substantial extract would remain non-Substantial. The cases I thought we were discussing here, are the real world requirements of 100'000 if not millions of objects that have to be bulk geo-coded. If these use cases are of no concern or don't actually exist, then it is not quite clear to me why we are having the discussion in the first place, given that: - on the fly geocoding is unproblematic (no database created) - a small number of geocoded results is non-Substantial and doesn't create share alike obligations. > > So it depends on how you'd store the results returned by the geocoder > and whether you'd store the input data with it. The logic is fairly clear. Assume you have a database of restaurant reviews, besides the review related data, every entry has restaurant name and street address. - I create a table with name and street address extracted from my database. - I geocode name and street address with OSM, adding the coordinates (or building polygons or whatever) to above table - I can now use this table (subject to the ODbL) and the original data together as a collective database to for example create a map with the restaurant locations or run a service that calculate routes to the restaurants on the fly. The important bit is not arguing about how the database is arranged and so on, but more that it gives us a model with which we can define precisely which data is subject to being available on ODbL terms. And yes in above example a user could ask you to give out the list of restaurant names, addresses and coordinates, which assuming that, for example, names could be missing in OSM, would actually be useful to the community. > Which brings us to point 2: > >>> 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). > > Now this interpretation together with the linked data concept of the > same Collective Database alternative (below) would mean that only data > directly retrieved from OSM would ever be covered by the ODbL. The ODbL > would not extend to any data added to the same database. Right? > As written in my original mail, the main issue is not so much that you can use similar data from a different source together with your dataset, the question is how do you do so without using information from OSM? Aka the fall back question. Re-visiting the example above: assume that the 2nd point is modified to be: - I geocode name and street address with OSM, adding the coordinates (or building polygons or whatever) to above table, if I don't find a match or the match in OSM doesn't fit my quality requirements, I geocode the name and address with a commercial database and store the results in a separate table. Is the 2nd table free of OSM rights? Not an easy question to answer. Note: http://osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline currently, on a similar issue, takes the stance that this is not something that is supported. Simon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
