API design for pointwise indexing

There have been a number of threads discussing possible improvements/extensions to xray indexing. The current indexing behavior for isel is orthogonal indexing - in other words, each coordinate is treated independently (see #214 and #411 for more discussion).

So the question: what is the best way to incorporate diagonal or pointwise indexing in xray? I see two main goals / applications:

1. support simple form of numpy style integer array indexing
2. support pointwise array indexing along coordinates via computation of nearest-neighbor indexes - I think this can also be thought of as a form of resampling.

Input from @WeatherGod, @wholmgren, and @shoyer would be great.

[duncanwp]

Further to the comment I made in a related issue #486 comment I’ve now taken a simplified version of the collocation approach in CIS and created a stand-alone package which works with xarray objects: https://github.com/cistools/collocate.

This works essentially the same as the nice example shown in the above blog, with some key differences:

• The points within a certain distance (tolerance) of each sample point can be aggregated or selected from using the built-in kernels, allowing fast operations over many sample points.
• The horizontal distance constraint can be supplemented with constraints in other dimensions (such as time or altitude).
• The transform from Cartesian to Eucledian coordinates is not needed as we use our own KD-Tree implementation which builds haversine rectangles. Depending on use cases this isn’t always the fastest approach, but it does sidestep some nasty dateline issues.
• In the case where only the nearest points in the horizontal is needed the collocation falls back the fast single point lookup.
• The KD-Tree implementation is (relatively well) separated so could easily be switched out for cKDtree or pyresample implementations
• There are a some tests too, although no docs yet.

I’ll try and put together a notebook building on the above blogpost so that the similarities and differences are a bit clearer.

I’m not familiar enough with xarray indexing to be able to say how well this would fit inside xarray, but hopefully it will be useful before we’re able to crack KD-MultiIndexes!

[benbovy]

Note that it will probably be easier to implement such KDTreeIndex after having refactored indexes and multi-indexes in xarray (see #1603). I think this refactoring would represent a good amount of work, though, so maybe we can do it after if you don’t want to wait too long for the KD-Tree feature?