Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Hi, On 07/17/2014 01:25 AM, Kai Krueger wrote: > For forward geocoding, the picture gets a bit more murky though, as the > distinction between what is for human consumption and what is data, and thus > a derived database, is much less clear cut. Indeed. If we were only talking about the "enter your address here and we'll zoom the map to your location" use case, we'd never be creating any database that contains OSM data in the first place. > However, once you start manipulating and computing with those lat/lon > values. E.g. to calculate the average distance between all of the POIs in > your proprietary db, I guess the most commercially interesting use case is: "I have a bunch of POIs or properties or client addresses and I want to be able to compute, at any time, for a given lat/lon, which of these are in the vicinity". The archetypal "where's the nearest pizza place" application comes to mind. This requires augmenting my proprietary database with lat/lons from OSM, else I would have to on-the-fly geocode half my database every time I want to make a query which would be too expensive. In your own distinction of "is this for human consumption or for a computer's", it is clearly for a computer's - since the coordinates form the basis for filtering which items to display to the user. A human wouldn't be able to sift through the list so quickly. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
Robert Whittaker (OSM lists) wrote > So the way I see it, if there's any (substantial) addition of external > geo-data along the way, then that addition creates a derivative > database, before the produced work is created. So if you want to > publicly use this database (or any produced work based on it) then > either the derivative database must be shared-alike, or the algorithm > used to produce it and any additional input data must be shared. > > In the case of any substanitial amount of geocoding, you are clearly > having to add additional geographic data to the OSM data in order to > do the geocoding. I would interpret it as quite the opposite and you are not adding any substantial amount of geographical information. You do query the db with external geo-data. But if the geocoder gives you a result, the information was (in this form) already in the OSM database and so you haven't added anything. If the data was not already in the OSM database, then the geocoder will not spit out any result and thus you haven't created any derived database (or anything else for that matter). So in either case, the result(s) from the geocoding process are pure OpenStreetMap data and there is no additional external geo-data added to the output. Therefore this process then also does not trigger the share-a-like clause in it self. And so as long as you don't use the resultant lat/lon in a way incompatible with the definition of produced work, geocoding itself is fine. -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811673.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Updated geocoding community guideline proposal
I thought I'd throw in my $0.02 into the discussion as well. First of all, I think it is good that we are having this discussion and I hope that eventually we can come to a OSMF sanction conclusion (set of community guidelines) one way or another. Overall, I think the route via produced works is the correct way to go here. For reverse geocoding I think declaring things as produced work is pretty well justified. The process is to take a geographic coordinate as input. This input is then turned, with the help of a bunch of complex algorithms(e.g. nominatum), into a (textual) rendering of an extract of the openstreetmap data. This textual rendering is then stored and eventually displayed to a human observer. This is nearly exactly equivalent to the process of rendering map tiles. I.e. you take four geographic coordinates (bounding box) as input. This input is then turned, with the help of a bunch of complex algorithms (e.g. mapnik), into a (bitmap) rendering of an extract of the openstreetmap data. This bitmap rendering is then stored and eventually displayed to a human observer. Given that map tiles are universally considered as produced works, so should imho be the result of reverse geocoding. As such, this should then also not trigger share-a-like. Just like one could take a proprietary database, use the stored lat/lon values in that database and render a 256x256 pixel image of the map for each entry of the database and store it back into the proprietary database without "infecting" the database with the ODbL share-a-like, one should be able to do the same with reverse geocoding. Imho anything that is intended for (more or less) direct consumption by humans is a produced work. For forward geocoding, the picture gets a bit more murky though, as the distinction between what is for human consumption and what is data, and thus a derived database, is much less clear cut. If you geocode an address and then all you do with the the resulting lat/lon is to display it in some form, then that is imho clearly also a produced work and thus shields things from the ODbL share-a-like requirement. However, once you start manipulating and computing with those lat/lon values. E.g. to calculate the average distance between all of the POIs in your proprietary db, the definition of produced work probably starts breaking down, because the output of the geocoding process is no longer the end product. Where exactly that line is though between produced work and derived database, I am not sure is obvious, and thus the intention of making the license clearer would unfortunately not really be achieved. Generally, I would consider my self as a proponent of share-a-like, but at least to me personally, I would consider all of the use cases presented in the proposed community guidelines as acceptable and within the spirit of share-a-like requirement for the OSM database. But it probably needs a bit more explanation of what you can and cannot do with the derived lat/lon values of the geocoding process. Kai -- View this message in context: http://gis.19327.n5.nabble.com/OSM-legal-talk-Updated-geocoding-community-guideline-proposal-tp5811077p5811672.html Sent from the Legal Talk mailing list archive at Nabble.com. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
