issue_comments

Thanks @shoyer . I think #412 suffices for this issue.

I will touch base regarding some point-wise/intersection/diagonal indexing (#214) when I return in July.

Added a warning in https://github.com/xray/xray/pull/412. Here's what that doc page looks like now:

The indexing details link you show does explain the behavior better but it is somewhat contradictory to the quote I listed above. I think it would be worth reconciling the docs on that point.

I'll definitely add a note to qualify that description in the docs -- sorry you went to all the trouble of writing up the bug report!

The station selection use case you bring up is exactly what I was going for. It would be nice if we could stay in xray / pandas after the indexing. Ideally, I don't want to do: xr_data.values[:, ys, xs] and then recreate a DataArray.

The open issue for this is #214, which describes how I currently do "diagonal" style indexing to extract stations. It preserves all the metadata, but is a little slow if you have a very long list of stations:.

Note that the example in that first comment will work even with arrays that don't fit into memory if you use dask (which will be in the next xray release, which will be out today or tomorrow).

Lastly, is there an issue open for support of numpy fancy indexing?

Full NumPy style fancy indexing is out of scope for xray. You can simply do way too many complex things with it for which preserving the metadata is impossible (e.g., you can scramble the elements of a 2D array into any arbitrary desired positions). Moreover, the underlying array indexing operations are only possible to do efficiently if the underlying array is backed by NumPy -- there's no way we'll do that with netCDF4 or dask.array. But more limited cases, such as the "diagonal" or intersection style array indexing you want here are definitely possible to support, and help for that would certainly be appreciated.

Okay. Glad to hear I was missing something. For large datasets, I was getting a MemoryError with orthogonal indexing as the array size increased like it did in my example.

The indexing details link you show does explain the behavior better but it is somewhat contradictory to the quote I listed above. I think it would be worth reconciling the docs on that point.

The station selection use case you bring up is exactly what I was going for. It would be nice if we could stay in xray / pandas after the indexing. Ideally, I don't want to do: xr_data.values[:, ys, xs] and then recreate a DataArray.

Lastly, is there an issue open for support of numpy fancy indexing? This is something that would be useful for my work and I could contribute to the effort beginning in July.

This is expected -- we do orthogonal indexing (treating each coordinate independently), not NumPy style fancy indexing. If you read on in the indexing docs, you'll find this under "Indexing details": http://xray.readthedocs.org/en/latest/indexing.html#indexing-details

Perhaps we should note this more prominently!

The style of indexing you're describing here is definitely useful, though (e.g., for selecting the locations of stations from a grid) -- it's something that I would really like to support.