issue_comments

http://notes.stefanomattia.net/2017/12/12/The-quest-to-find-the-closest-ground-pixel/

@stefanomattia - I'd be happy to provide guidance and even to contribute to some of the development. Based on your blog post, I think you may be well on your way.

ping @stefanomattia who seems to be interested in the KDTreeIndex concepts described in this issue.

@WeatherGod

Short answer. We don't have a tool that is production ready.

Longer answer: xESMF may be the best prospect in the near term. There are two main issues with its current implementation. 1) Lack of out-of-core abilities / integration with dask, and 2) lack of a test suite. Conceptually, it would be great to leverage the low-level remapping tools of ESMPy so I think this is a nice way to move forward as a community but I think everyone agrees it isn't ready for use in any sort of production environment.

This issue introduces the concept of point-wise indexing using nearest neighbor lookups on ND coordinates. @shoyer has an example implementation here but it hasn't moved forward in quite a while.

Very nice. This is the sort of API I was hoping for. It will be a while before I can come back around on this. In the meantime, if someone else wants to take the sel_points method on, that is fine by me.

Now that the isel_points method is implemented, I think it makes sense to discuss the sel_points method in a bit more detail. The main outstanding question is - do we want to support spherical nearest neighbor mapping. The use case is when you are searching for the nearest neighbor using longitudes and latitudes. This example shows an example of to do this by projecting the coordinates onto a sphere. If we go this route, which is probably the most common use case here, we are committing to the coordinates being latitudes and longitudes. Maybe it is better to use a method='spherical' keyword to fall into this path.

Good point on the dask array business. From the dask docs:

Dask.array supports most of the NumPy slicing syntax. ... It does not currently support the following:

Slicing one dask.array with another x[x > 0] Slicing with lists in multiple axes x[[1, 2, 3], [3, 2, 1]]

Both of these are straightforward to add though. If you have a use case then raise an issue.

So, from browsing the closed dask issues, it seems like dask has similar support for multi-dimension slicing and indexing as xray. This throws a bit of a wrench in my plan for how I was going to implement isel_points as I had not fully considered the dask array complexities.

I'll have to put a bit more thought into this. Any suggestions on how to index the dask array without looping through individual points would be great.

As a first step, I'll volunteer (unless someone else is more keen on doing this work) to put together a pull request for isel_points.

After that, we'll want to add the sel_points and kdtree API, which will depend on isel_points.

Later on, I'm also interested in regridding and resampling between grids - let's open another issue for that. Maybe we use pyresample for that.

I like:

python DataArray.isel_points(x=[1, 2, 3], y=[0, 1, 2], dim='points')

I also like the nearest-neighbor / resample API of:

python DataArray.sel_points(lon=[-123.25, -140.0, 72.5], lat=[45.0, 72.25, 65.75], dim='points', method='nearest')

How do we want to do the nearest-neighbor selection? The simplest case would be to follow the cKDTree example from #214. However, when you're using lat/lon coordinates, it is usually best to map these coordinates from the spherical coordinates to a Cartesian coordinates (see here for a simple example using cKDTree. Is that a road we want to go down here?

Further along that subject, but not directly relate - has anyone used pyresample.