What happened?

for a dataframe with a detailed timestamp coordinate (2022-03-11T13:50:50.551314000)

da.sel(time="2022-03-11") works but da.drop_sel(time="2022-03-11") results in a KeyError

What did you expect to happen?

i expect drop_sel() to work with the same inputs as sel()

Minimal Complete Verifiable Example

```Python import numpy as np import xarray as xr times = np.array(['2022-03-03T13:50:49.548072000', '2022-03-11T13:50:50.551314000', '2022-03-12T13:44:35.547024000', '2022-03-13T12:18:48.015182000'], dtype='datetime64[ns]')

da = xr.DataArray(np.arange(4), dims="time", coords={"time": times}) da.drop_sel(time='2022-03-11') ```

A workaround is to use the exact datestring: da.drop_sel(time='2022-03-11T13:50:50.551314000')

MVCE confirmation

• [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• [X] Complete example — the example is self-contained, including all data and the text of any traceback.
• [X] Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• [X] New issue — a search of GitHub Issues suggests this is not a duplicate.

Relevant log output

```Python

KeyError Traceback (most recent call last) Cell In[4], line 1 ----> 1 da.drop_sel(time='2022-03-11')

File ~/.local/envs/xvec/lib/python3.11/site-packages/xarray/core/dataarray.py:3105, in DataArray.drop_sel(self, labels, errors, **labels_kwargs) 3102 if labels_kwargs or isinstance(labels, dict): 3103 labels = either_dict_or_kwargs(labels, labels_kwargs, "drop") -> 3105 ds = self._to_temp_dataset().drop_sel(labels, errors=errors) 3106 return self._from_temp_dataset(ds)

File ~/.local/envs/xvec/lib/python3.11/site-packages/xarray/core/dataset.py:5292, in Dataset.drop_sel(self, labels, errors, **labels_kwargs) 5290 except KeyError: 5291 raise ValueError(f"dimension {dim!r} does not have coordinate labels") -> 5292 new_index = index.drop(labels_for_dim, errors=errors) 5293 ds = ds.loc[{dim: new_index}] 5294 return ds

File ~/.local/envs/xvec/lib/python3.11/site-packages/pandas/core/indexes/base.py:6934, in Index.drop(self, labels, errors) 6932 if mask.any(): 6933 if errors != "ignore": -> 6934 raise KeyError(f"{list(labels[mask])} not found in axis") 6935 indexer = indexer[~mask] 6936 return self.delete(indexer)

KeyError: "['2022-03-11'] not found in axis" ```

Anything else we need to know?

related to https://github.com/pydata/xarray/issues/6605#issuecomment-1126139617

Environment

(xarray: 2023.3.0)

What happened: Tried to follow http://xarray.pydata.org/en/stable/io.html#opendap with @wycheng-uw and ran into a massive traceback ending with RuntimeError: NetCDF: file not found

What you expected to happen: Expecting to successfully plot data as illustrated in documentation

Minimal Complete Verifiable Example:

python remote_data = xr.open_dataset("http://iridl.ldeo.columbia.edu/SOURCES/.OSU/.PRISM/.monthly/dods", decode_times=False) tmax = remote_data["tmax"][:500, ::3, ::3] tmax[0].plot()

Anything else we need to know?:

After digging through unresolved opendap issues (https://github.com/Unidata/netcdf4-python/issues/755, https://github.com/pydata/xarray/issues/3466, https://github.com/pydata/xarray/issues/4353)

https://github.com/pydata/xarray/issues/3580 provided the key workaround that netCDF4>1.5.1 seems to cause issues. Pinning netCDF4==1.5.1 is our current workaround. Not sure if this is specific to http://iridl.ldeo.columbia.edu/ or OpenDAP endpoints more generally...

Environment:

xarray 11.3 currently won't read HDF5 file-like objects

```python import xarray as xr import gcsfs fs = gcsfs.GCSFileSystem() images = fs.ls('pangeo-data/grfn-v2/137/') fileObj = fs.open('pangeo-data/grfn-v2/137/S1-GUNW-A-R-137-tops-20181129_20181123-020010-43220N_41518N-PP-e2c7-v2_0_0.nc')

but, can we open this w/ xarray anyway? Yes! with modifications to xarray and h5netcdf

da = xr.open_dataset(fileObj, group='/science/grids/data', engine='h5netcdf') da ```

```pytb

ValueError Traceback (most recent call last) <ipython-input-3-22e0010de1f2> in <module>() 1 # but, can we open this w/ xarray anyway? Yes! with modifications to xarray and h5netcdf ----> 2 da = xr.open_dataset(fileObj, group='/science/grids/data', engine='h5netcdf') 3 da

/srv/conda/lib/python3.6/site-packages/xarray/backends/api.py in open_dataset(filename_or_obj, group, decode_cf, mask_and_scale, decode_times, autoclose, concat_characters, decode_coords, engine, chunks, lock, cache, drop_variables, backend_kwargs) 347 else: 348 if engine is not None and engine != 'scipy': --> 349 raise ValueError('can only read file-like objects with ' 350 "default engine or engine='scipy'") 351 # assume filename_or_obj is a file-like object

ValueError: can only read file-like objects with default engine or engine='scipy' ```

Problem description

It is now possible to do this with h5py >2.9.0. see https://github.com/h5py/h5py/pull/1105. This would be a useful feature because there is a lot of NASA data out there in HDF5. This functionality could open up reading without first writing to disk (to translate to Zarr or other formats possibly). There seem to be many issues related to this: https://github.com/dask/s3fs/issues/144 https://github.com/pydata/xarray/issues/2535

I'm guessing adding this functionality doesn't fix many of the performance issues related to HDF5 and Dask https://github.com/dask/dask/issues/2488 https://github.com/dask/distributed/issues/2319

Expected Output

<xarray.Dataset> Dimensions: (latitude: 2045, longitude: 4158) Coordinates: * longitude (longitude) float64 -123.1 -123.1 ... -119.6 -119.6 * latitude (latitude) float64 43.22 43.22 43.22 ... 41.52 41.52 Data variables: crs int32 ... unwrappedPhase (latitude, longitude) float32 ... coherence (latitude, longitude) float32 ... connectedComponents (latitude, longitude) float32 ... amplitude (latitude, longitude) float32 ...

Output of xr.show_versions()

This is not a bug, but rather a feature request and discussion opener for changes to the open_rasterio function

Currently open_rasterio (xarray version 0.11) only accepts filepath strings and does not work with In-memory rasterio.vrt.WarpedVRT objects. I have a solution (see pull request), but it's likely not the best one (Many context managers can feel odd), see example below:

```python

Lazy in-memory warping from UTM to WGS84 lat/lon

with env: with rasterio.open(url) as src: da = xr.open_rasterio(src) print(da.crs, da.sizes) with WarpedVRT(src, crs='epsg:4326') as vrt: with xr.open_rasterio(vrt) as da: print(da.crs, da.sizes)

+init=epsg:32610 (1, 7531, 7751)

+init=epsg:4326 +no_defs (1, 5981, 9183)

``` More detailed gist here: https://gist.github.com/scottyhq/ae90084adaf25e3b361b096d555c45f1

Problem description

In-memory “virtual” reprojection is a key feature of rasterio (see https://gist.github.com/sgillies/7e5cd548110a5b4d45ac1a1d93cb17a3), and it would be fantastic if this worked w/ xarray and dask distributed. Many workflows require warping between WGS84 lat/lon, UTM, Google Mercator, and rasterio can handle most any other projection.

related to: #1575, #2042, #2288 https://github.com/dask/dask/issues/3255 Seems like some synergy here with geoxarray and salem @mrocklin, @fmaussion, @geoxarray