You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: don-vip [Submitted to the original trac issue database at 4.41pm, Tuesday, 31st July 2012]
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):
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.
The text was updated successfully, but these errors were encountered:
Author: TomH [Added to the original trac issue at 6.11pm, Tuesday, 31st July 2012]
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.
Author: don-vip [Added to the original trac issue at 8.58pm, Tuesday, 31st July 2012]
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.
Author: Gnonthgol [Added to the original trac issue at 6.22pm, Thursday, 2nd August 2012]
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.
Reporter: don-vip
[Submitted to the original trac issue database at 4.41pm, Tuesday, 31st July 2012]
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.
The text was updated successfully, but these errors were encountered: