Skip to content
This repository was archived by the owner on Aug 5, 2022. It is now read-only.

Test/Handle Big Requests #6

Open
chriswhong opened this issue Apr 29, 2016 · 3 comments
Open

Test/Handle Big Requests #6

chriswhong opened this issue Apr 29, 2016 · 3 comments
Milestone

Comments

@chriswhong
Copy link
Contributor

What should the app do if the request is too big (so much returned that rendering it in leaflet will be problematic).

Should it just be a row limit with a message saying the response is truncated, or should the API not send anything if it's going to be too big?

@mgd722
Copy link
Contributor

mgd722 commented May 29, 2016

My thoughts would be to send a truncated response. Are you familiar with the rendering limits of leaflet? I haven't ran into any yet, but I don't often run massive queries.

@chriswhong
Copy link
Contributor Author

AFAIK "thousands" of elements on the map is when leaflet will start to chug. Not sure if truncation is the right approach, I think it should either give you what you asked for or not.

@brianbancroft brianbancroft added this to the 0.2.0 milestone Aug 1, 2018
@chriswhong
Copy link
Contributor Author

The vector tiles should help with this, but as @PaulRamsay pointed out on twitter, the table view is the resource hog.

We should add a proper API endpoint for paginated CSV results for the table view.

@adieng01 adieng01 removed the 🐛 bug label Jun 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants