It's OK - I think @shoyer is right - it shouldn't silently promote the type, and the error message is clear. Thanks

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!

This looks good to go now - thanks for all your help!

Ah yes, sorry about that - fixed now.

Yep, it's not a very exciting cube, but it runs fine.

How's this? (I turned the example around so that I create the cube as a DataArray then convert it...)

dask/dask#2977 would certianly make it cleaner, but 95b0197 should work in the meantime, unless there's a specific case I've missed?

Great - thanks!

OK, here's another go. It's not pretty, but it seems to work. Once the various issues referenced above are solved it should clean it up, but I'd rather not wait for those since this has been in the works a while now.

Thanks for the feedback @shoyer and sorry for all the typos!

I think this may be a reasonable place to start, though it is certainly not leveraging Iris's full metadata decoding capabilities.

It seams like a decent starting point, were there specific decodings you had in mind?

It would also be nice to pass dask arrays back and forth, but that will probably need to wait until after Iris 2.0 and #1372 is solved.

Agreed.

Do you have a feel for if/where else this should be documented? I'm not sure if really fits in I/O...

I'm happy to pick this up - I'm not sure how best to pick up someone else's pull request though. Am I best off forking nparley:master then resubmitting, or creating a new one and merging in the changes from nparley:master?

Yes, you're right - it works now in 0.10.0rc1. Apologies for the noise!

@jhamman @godfrey4000 - I'm not sure of the status of this, but I'm the lead developer on a package called CIS which might be useful/relevant.

It was designed as a command line tool to allow easy collocation (resampling) between different model and observation datasets, but is now also a Python library. We spent a fair amount of time thinking about the various permutations and you can see some of the details in our paper here. Internally we currently use Iris Cube-like objects but it would be pretty easy to operate on xarray Datasets since they share a similar design.

The basic syntax is: ``` from CIS import read_data X = read_data('some_obs_data.nc') Y = read_data('some_other_data.nc') X.sampled_from(Y)

or...

Y.collocated_onto(X) `` Happy to discuss further here, or inxmap`.