Initial API call over 10mb

[smit1678]

Our initial API call for loading the browser is over 10mb. This is quite slow in a low bandwidth environment. But also you see the difference between the Latest imagery loading in the sidebar (smaller call, 22kb) and the main call for the map.

Idea for improving this: move to a filtered API call on load. Load with the filter in place for High resolution and within the Last month.

[smit1678]

I looked into this and attempted to play around with some solutions. One being, adjusting our main API query: https://github.com/hotosm/oam-browser/blob/oauth-login/src/stores/map_store.js#L61. Adjusting this to a limit that is lower reduces the size.

But it seems that all resulting views of the map are based on the initial API query. So when we limit this, then some data is never exposed through the grid.

[mojodna]

Because that call is used to initialize the state, I don't think there's a quick way to address this. We should probably be making tiled requests for imagery metadata (returning JSON with a max zoom). To avoid the initial load still being 10MB (split across multiple requests), only imagery sources that are large enough to be visible at a given zoom level based on their footprint could appear in a given tile response.

The app's state would be continuously updated as users pan around, loading additional metadata for imagery that becomes visible.

[smit1678]

The app's state would be continuously updated as users pan around, loading additional metadata for imagery that becomes visible.

Yeah. Also related to the issues hotosm/OpenAerialMap#95 and https://github.com/hotosm/OpenAerialMap/issues/100

@sharkinsspatial Thoughts on how we could approach this? Also related to our discussion around making the codebase more maintenance friendly.