Provide imagery blacklist in API capabilities #5024
Comments
Author: pnorman Pros:
Cons:
From my point of view, yes, preventing the use of layers commonly used for infringing purposes is part of the job of editing software. |
Author: TomH Well I assume that if we did it we would then encourage P2 and iD to take their lists from the API otherwise it would all be a bit pointless. |
Author: woodpeck @pnorman, your reasoning only holds if you assume that the OpenStreetMap API with its current license is the only API against which the editing software will be used. If someone were to use any of the programs to connect to a system that uses the OSM API but is licensed differently, then image sources that are not allowed for OSM might become available or vice versa. So, which imagery is allowed depends not on the editor but on the API (and project) the editor connects to. This might be less of an issue for iD or P2 which would likely have to be embedded into that new system anyway, but JOSM - or any other standalone editor for that matter - doesn't require a code change to be used with different servers. |
Author: don-vip [https://docs.google.com/document/d/1uemhXWKwbu3RNjAWcG0R-nEFaN1FHjZl1McFwjXkNSc/pub some LWG activity from Feb 25th] stating:
The next meeting was scheduled on March 25th but I can't find the minutes? |
Author: pnorman The LWG recommends adding the imagery blacklist information to the capabilities API and that once it has been added editor clients shift to using it. Paul Norman \ For the Legal Working Group |
Author: pnorman So, there's a schema question here, how do we best define it? One idea suggested was
It's possible that some clients may not have regular expression capabilities, and there's a number of different regex variants, which means we'd have to specify what we were using. I'm also not sure that we'd actually need regular expressions. don-vip, as you're the requester for the enhancement, any thoughts? |
Author: don-vip Thanks for the update. I think we should stick to the format defined and implemented by Frederik years ago. Implementing it now in the API should result in all JOSM clients honor it, even the oldest ones, even Mac OSX users stuck with Java 6, and so on: <api>
...
</api>
<policy>
<imagery>
<blacklist regex=".*\.google\.com/.*" />
<blacklist regex=".*209\.85\.2\d\d.*" />
<blacklist regex=".*209\.85\.1[3-9]\d.*" />
<blacklist regex=".*209\.85\.12[89].*" />
</imagery>
</policy> We should however test it first against http://api06.dev.openstreetmap.org as this part of JOSM code has never really been used since. |
Author: stoecker Hmm, was implemented inbetween it seems. |
Reporter: don-vip
[Submitted to the original trac issue database at 10.22am, Thursday, 31st October 2013]
We have in JOSM, thanks to Frederik and since february 2011, a support for imagery blacklist provided by API capabilities, see:
http://josm.openstreetmap.de/changeset/3934/josm
http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/io/Capabilities.java#L15
However, it seems this has never been implemented on server side. I don't even know if it has been asked, that's why I ask here if it's possible to add it :)
Instead, we currently have a hard-coded list that Paul asked us to update few days ago. It would be better to define it in the API if we really want to enforce this blacklist (not all users upgrade their JOSM version as soon as we'd like to)
See http://josm.openstreetmap.de/ticket/9210
The text was updated successfully, but these errors were encountered: