Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Include API usage policy technical limitations into Capabilities #4501

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments
Closed

Include API usage policy technical limitations into Capabilities #4501

openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments
Assignees
@openstreetmap-trac
Labels
Component: api Priority: minor Resolution: wontfix Type: enhancement

Comments

@openstreetmap-trac
Copy link

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.
@openstreetmap-trac openstreetmap-trac self-assigned this Jul 23, 2021
@openstreetmap-trac
Copy link
Author

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.

@openstreetmap-trac
Copy link
Author

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.

@openstreetmap-trac
Copy link
Author

Author: TomH
[Added to the original trac issue at 9.28pm, Tuesday, 31st July 2012]

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.

@openstreetmap-trac
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@openstreetmap-trac openstreetmap-trac

Labels
Component: api Priority: minor Resolution: wontfix Type: enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openstreetmap-trac