Description
Its really useful to calculate the jaccard score (IOU) when doing spatial queries against really any catalog. The score returns a 1.0 if the search geometry and item geometry are identical, and a 0.0 if the two geometries are very different. You can make the jaccard score inclusive by instead using the intersection of the search and item geometry for the calculation. This effectively returns a score of 1.0 if the search geometry is completely contained by an asset.
This is really useful for clients which care about how item geometries compare to the request geometry past the typical intersects/contains operations. A good example of this is mosaic tiling, where the goal is to use some sort of index (whether it is mosaicjson, postgres etc.) to reduce number of HTTP requests sent to rasters by minimizing the search space. In this case, the tiler can sort the /search response by score and more intelligently send requests to fill that particular tile.
This is one of the downsides of mosaicjson. Because you have to seed it at a particular quadkey (which may or may not align well with your data), the tiler really doesn't have an understanding of what assets cover which tiles at higher zooms than the seed. The result is the tiler has to naively send tile requests to every asset until the particular tile is full which could be avoided if the index does a better job minimizing the search space