Restrict compare tool to overlapping AOI's

[LanesGood]

This is a proposal for the compare tool, not yet established whether technically feasible, nor entered into the designs.

We know that the main use case for comparing prediction maps will be to look at change over time. This will most often and most likely be single users or related groups producing exported AOIs with the same imagery, model, and checkpoint, and changes in the mosaic.

It could be possible that users would want to compare LULC predictions from different imagery sources, different models, and different checkpoints.

However, it seems highly unlikely that users would want to compare any differences between these inputs in different geographies. It is difficult to imagine how this would be useful; in order to see prediction tiles on the share map, users must be zoomed in to the min-zoom, so it would not be possible to look in two areas that are far apart.

Would it be possible to restrict the compare tool to only AOI's that overlap? As we save the bounds for each AOI, I imagine we could run something like turf.js boolean instersect to determine which AOIs are eligible for comparison after the first AOI is selected. However, I recognize that this may be a complex operation to run over every possible available AOI and could require some complex engineering.

@vgeorge @geohacker what do you think?

[geohacker]

@LanesGood I really like this idea but like you point out this will be computationally quite intensive on the frontend. We can try to implement after the compare functionality is implemented. The more efficient way is probably to have a endpoint on the backend that returns all available AOIs to compare for a selected AOI, but that's a bunch of work we may not have time for right now.

[LanesGood]

For learning purposes, is it intensive because there is a property that needs to be compared to every other object, or is it mostly because its a geospatial operation?

[geohacker]

@LanesGood yes both, doing an intersect of one polygon to n number of other polygons is going to be both unpredictable and inefficient on the clientside.