Luis The LWG has spent considerable time discussing the "geocoding issue", so it is not as if we've ignored the subject.
To illustrate just one of the issues, have a look at the first mail you reference from Olov, he defines Geocoding as "The process of finding and storing the latitude and longitude coordinates for an entity." He then continues to say " ... returning the latitude and longitude coordinates associated with the matching OSM object." and "... to find the latitude and longitude coordinates associated with a point or an area, .... Skipping the tiny weeny issue, that ways and areas are not point objects and do not have a latitude and longitude associated with them. Naturally you can calculate a centroid for 2d objects and use that in lieu of the actual geometry of the object, but does that imply that we should treat such geocoding results different than those from point objects? BTW the main OSM geocoding service returns the actual geometry of found objects, so I suppose it doesn't geocode :-). So, yes, I think it might be fair to say that the LWG has punted on the geocoding issue at least for now, to spend its time on issues which are more likely to be resolved. Simon PS: the absence of a guideline to the contrary I would suggest that it is prudent to assume that the results of geocoding (whatever it is ) a substantial number of addresses or other information with OSM is a derivative database. However I don't believe that this has any big consequences in reality, outside of that the results have to be maintained in an independent database. Am 08.05.2014 01:27, schrieb Luis Villa: > > On Sat, May 3, 2014 at 7:54 AM, Michael Collinson <m...@ayeltd.biz > <mailto:m...@ayeltd.biz>> wrote: > > > We also have a number of issues that are very immature in terms of > constructing a useful guideline. What we have been lacking, with > some notable exceptions, is data users prepared to give a real use > case that they can share in a reasonable level of detail. Being > able to deal with concrete rather than myriad hypothetical cases > makes progress much faster. If you are user or potential user of OSM > data, do share real-world issues here. Or, contact us at > le...@osmfoundation.org <mailto:le...@osmfoundation.org>. We can > handle commercial-in-confidence provided that the end result is > shareable publicly and applies to all equally within the parameters > of our license. > > > I would suggest that writing down and working through even basic, > non-detailed use cases would likely help clarify a lot of the > Guidelines. Even if all they do is result in saying "it depends", > explaining what it depends on can be helpful to everyone. > > For example, to kickstart the geocoding Guideline, it would probably be > great to start with some of the basic examples/use cases from the > mailing list discussion last year: > https://lists.openstreetmap.org/pipermail/legal-talk/2013-June/007553.html > and https://lists.openstreetmap.org/pipermail/legal-talk/2013-June/007554.html > > Which isn't to say that people shouldn't describe detailed use cases :) > Just that a lot of progress could be made by walking through more basic > ones as well. > > Luis > > -- > Luis Villa > Deputy General Counsel > Wikimedia Foundation > 415.839.6885 ext. 6810 > > NOTICE: /This message may be confidential or legally privileged. If you > have received it by accident, please delete it and let us know about the > mistake. As an attorney for the Wikimedia Foundation, for legal/ethical > reasons I cannot give legal advice to, or serve as a lawyer for, > community members, volunteers, or staff members in their > personal**capacity./ > > > _______________________________________________ > legal-talk mailing list > legal-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/legal-talk >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
