Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4501 closed enhancement (wontfix)

Include API usage policy technical limitations into Capabilities

Reported by: don-vip Owned by: rails-dev@…
Priority: minor Milestone:
Component: api Version:
Keywords: download threads usage policy capabilities Cc:

Description

We are currently working on a change in JOSM in order to download data with several concurrent threads, up to to the maximum number allowed by the OSM API usage policy (currently 2):

http://wiki.openstreetmap.org/wiki/API_usage_policy#Technical_Usage_Requirements

http://josm.openstreetmap.de/ticket/7914

Problem is: the usage policy may be subject to change without anyone noticing in our team. Worst, after such a change, all contributors using an older version of JOSM could make queries that do not respect the updated usage policy.

For these reasons, I would like to know it it is possible to include the maximum number of download threads in the response to GET /api/capabilities.

That would allow all running JOSM instances, old and new, to automatically comply to the current usage policy.

Change History (4)

comment:1 Changed 7 years ago by Tom Hughes

Resolution: wontfix
Status: newclosed

I would expect a client like JOSM to only download one thing at a time anyway, as it should only be downloading in response to a specific user request to download an area.

More generally, that document specifies limits, not targets, so I don't want to do anything that encourages people to engage in attempting to maximise their usage up to those limits.

comment:2 Changed 7 years ago by don-vip

This feature does not concern areas but when JOSM downloads a list of known primitives. This occurs when you wan to update data of download incomplete members of a relation, for example.

comment:3 Changed 7 years ago by Tom Hughes

Those calls are far worse than the map call for the API though, so really shouldn't be run in parallel until they are moved into cgimap.

comment:4 Changed 7 years ago by Gnonthgol

My continuous download plugin have this feature already where it runs multiple /map calls at once. The default is to run 2 threads but this is user configurable (maybe I should set a max). This is a nice feature when downloading multiple bboxes.

If you specify a max threads somewhere (in /capabilities or as a special return header for the call) I would rewrite the plugin to honor that.

Note: See TracTickets for help on using tickets.