First a general comment: I would in general refer to the "Collective Database" guideline as it is essentially an extension of the ideas first formulated there and a bit more rigorous in its treatment of the subject matter.
When we created the "Horizontal Layer" guideline, while not explicitly said, the question was in the end the same as with the "Collective Database" guideline: how much interaction can we allow between two datasets and consider them independent, which in turn led to the de-duplication ban. Now what we didn't touch on (in both guidelines), mainly because it it is slightly contrary to usual GIS business practice and wasn't a use case on the table at that point in time, is the other way of avoiding de-duplication: simply lumping everything together. Given that by the very definition two such lumped together datasets are independent, there is no reason to believe that they would not meet the ODbL definition of a "Collective Database" (note IMHO de-duping would include deliberately visually obscuring OSM data, but it seems that maps.me is squeaky clean in that respect). Simon Am 06.08.2016 um 20:11 schrieb Stewart C. Russell: > Hi - > > I followed last month's discussion* from afar with interest. I hope I'm > not flogging an utterly dead horse here, but I made a few discoveries in > comparing local maps.me data around Toronto with OSM nodes: > > 1) Initially, maps.me was removing obviously identical hotel nodes (same > name, very close location), and replacing them with booking.com data. > Non-matching OSM nodes were left, so if a mapper had put a typo in the > name or tagged a different building in a hotel complex, maps.me showed > both. This scenario is clearly not allowed by the OSMF guidelines. > > 2) Now it seems that *all* OSM hotel nodes are included, along with > (some? all?) booking.com hotel properties. The booking.com nodes have a > slightly higher profile, but they appear mixed together in search results. > > 3) The skipped nodes list (formerly at > http://direct.mapswithme.com/direct/latest/skipped_nodes.lst) is now no > longer published. The last version I reviewed (from 2016-07-31) was very > clearly close matches to booking.com's database. In a way, since it was > compared against a proprietary database, the skipped nodes list was > derived from booking.com's data. I'm not sure booking.com would be happy > about this use of their data. > > It would seem that the guidelines would only allow the mixing of a > booking.com proprietary horizontal layer, paraphrasing mechanically from > “restaurant” to “[hotel]”: > > You use OpenStreetMap as a base topographical > map and make your best reasonable efforts to > exclude ALL [hotel]s. You then add a layer of > your own [hotel] data. > > I'm not seeing this in the maps.me app. > > cheers, > Stewart > > *: starting here: > https://lists.openstreetmap.org/pipermail/legal-talk/2016-July/008468.html > > _______________________________________________ > 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
