Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi Fetch GET with /full option? #2348

Open
bhousel opened this issue Aug 12, 2019 · 3 comments
Open

Multi Fetch GET with /full option? #2348

bhousel opened this issue Aug 12, 2019 · 3 comments
Labels
api Related to the XML or JSON APIs

Comments

@bhousel
Copy link
Member

bhousel commented Aug 12, 2019

Per openstreetmap/iD#6668 (comment)
iD is using the Multi Fetch GET API call in a few situations to fetch ways and relations:

  • downloading additional member ways for correct handling of multipolygons, routes, etc.
  • checking and dealing with error 409 conflicts at save time

Unfortunately we need to still perform more calls after this to get all the related nodes (and this can be a lot of nodes).

It would be really great if we could have a version of this call that works like the /full Single Fetch GET call that returns all the related nodes in the response.

cc @mmd-osm

@gravitystorm
Copy link
Collaborator

Seems reasonable to me.

@gravitystorm gravitystorm added the api Related to the XML or JSON APIs label Aug 21, 2019
@mmd-osm
Copy link
Collaborator

mmd-osm commented Aug 22, 2019

As I mentioned in the linked issue, we still need to sort out, how the new "multi fetch with full option" is exposed via the API. Should we extend the existing endpoint (if so, how exactly should that look like?), or would it make more sense to define a new endpoint?
That's more or less the same level of detail you would need to update the OSM API documentation in the WIki.

@pnorman
Copy link
Contributor

pnorman commented Apr 14, 2020

As I mentioned in the linked issue, we still need to sort out, how the new "multi fetch with full option" is exposed via the API. Should we extend the existing endpoint (if so, how exactly should that look like?), or would it make more sense to define a new endpoint?

Any opinions on this from those who want the new endpoint?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Related to the XML or JSON APIs
Projects
None yet
Development

No branches or pull requests

4 participants