make computation resolution dynamic (improve performance)

[harry-gibson]

It is difficult to pick an appropriate computationScale for the cumulativeCost call to allow the map to be reasonably interactive but ensure consistent results.

• If computationScale isn't fixed then performance is good when zoomed out as an appropriate resolution is chosen automatically. However the numeric value of results (queried by clicking the map) changes with zoom. Performance when zoomed in becomes very poor.
• If it is fixed (on the cumulativeCost call) then picking a value is hard:
  • too coarse and the map looks rubbish when we zoom in (and results are wrong, though at least constant);
  • fixed at native 1k resolution and map is far too slow to use interactively.

The interactive map is restricted to max zoom level of 9 which is c.305m/pixel at the equator.

To date the tool has been configured with a fixed computationScale of 2445m (AccessToolConstants.INTERACTIVE_RESOLUTION)which means the output pixels are ~8*8 screen pixels at the highest allowed map zoom level. This keeps things usable but it's still slow (too fine) when zoomed out, and looks a little blocky when zoomed in as far as possible.

How to make the map more timely but without disrupting accuracy too much, or at least, inconsistently?

It seems that ideally we would fix the computation scale in some circumstances but not others. For example allow the API to pick a resolution automatically when zoomed out but have a floor that is say 3* actual pixel size when zoomed in, and certainly never finer than the 1k native resolution of the data.

Also for querying the map, this should be done at a fixed computationScale regardless of map zoom so that clicking in a given place always gives same result. It's probably always too slow to do this at AccessToolConstants.NATIVE_RESOLUTION, though, so results will always be inaccurate.

[harry-gibson]

The issue is that once the map has been created, python is out of the loop and we just have Maps API talking to EE, so I don't see that we can change computationScale according to zoom. Is this correct? If so could we:

• create two (or more) requests to costpath with different computationScales (or not set on one of them) and return a mapid for each, for the JS to flip between them as appropriate according to scale
• how do we achieve timely response on interactive query without click at a given point giving a different result at different zooms - might have to fix computation scale for this at some intermediate value?