Slow response with API endpoint "/projects/{id}.json"

[sanak]

Problem
There is already /projects.json include=geometry filter, but similar filter is preferable also for /projects/{id}.json, because of slow response.

To Reproduce
Specify big size polygon as project's geometry, then access to /projects/{id}.json.

Expectation
Currently, the request takes around 1 ~ 2 sec,
but if possible, default = none geometry seems to be good.

[dkastl]

Why is the response slow?
Because of the size of the response due to large GeoJSON content?

Maybe we should think about users uploading too detailed polygons, which are often too big and can be simplified. Eventually we could simplify geometries and make it optional to include the original one.

[sanak]

@dkastl

Why is the response slow?
Because of the size of the response due to large GeoJSON content?

Yes.

Maybe we should think about users uploading too detailed polygons, which are often too big and can be simplified. Eventually we could simplify geometries and make it optional to include the original one.

Okay, but I will try to check why detailed polygon is so slow, at first.

[dkastl]

For projects list there is already include=geometry as request parameter available, but for individual projects the geometry must be really huge to produce a slow response. And this response will not only be slow via API but also on the application side.

So I think it would be best to:

• lower the accuracy of geometries as in Shorten WKT coordinates (limit decimals) #7
• see how we can prevent users to upload huge polygons ... maybe a warning before uploading a very large polygon would be enough? But what is "very large". We could also just mention it in the documentation.