Opened 5 years ago

Closed 2 years ago

#5024 closed enhancement (fixed)

Provide imagery blacklist in API capabilities

Reported by: don-vip Owned by: rails-dev@…
Priority: major Milestone:
Component: api Version:
Keywords: capabilities imagery blacklist Cc:


We have in JOSM, thanks to Frederik and since february 2011, a support for imagery blacklist provided by API capabilities, see:

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)


Change History (8)

comment:1 Changed 5 years ago by pnorman


  • Has a central list
  • Easier updating
  • Changes would cover JOSM back to 2011


  • P2 and iD define their blacklists internally, is there a reason JOSM can't do the same
  • Would only effect JOSM
  • Adds a new <policy/> element to the API capabilities document, which is a wider change then just updating JOSM's list

From my point of view, yes, preventing the use of layers commonly used for infringing purposes is part of the job of editing software.

comment:2 Changed 5 years ago by Tom Hughes

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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by don-vip

some LWG activity from Feb 25th stating:

Getting JOSM’s blacklist update is important for the DWG, be it by modifying the API to return a blacklist or not. The question is, should this be delivered by the OpenStreetMap API? The positive is that it actively helps prevent well meaning map data and editor software contributors from contaminating the OSM database with data from non-allowed sources. The potential negative to this is that it may imply that other source not on the blacklist are OK. After discussion, it was felt that the right balance could be struck by additionally adding a whitelist, which may also be of use in its own right. Therefore:

LWG recommends and supports an API-delivered blacklist AND whitelist. We urge that it be made clear in supporting documentation that if a source is not on the blacklist, that does not imply that it OK and research should be done before adding it.

Potential whitelist

The next meeting was scheduled on March 25th but I can't find the minutes?

comment:5 Changed 5 years ago by 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

comment:6 Changed 5 years ago by pnorman

So, there's a schema question here, how do we best define it?

One idea suggested was

  <if-match pattern="foo"/>
  <if-match pattern="bar"/>

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?

comment:7 Changed 5 years ago by 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:

    <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].*" />

We should however test it first against as this part of JOSM code has never really been used since.

comment:8 Changed 2 years ago by Dirk Stoecker

Resolution: fixed
Status: newclosed

Hmm, was implemented inbetween it seems.

Note: See TracTickets for help on using tickets.