Pre-validate asset media_type before xr.open_dataset to fail clearly on non-Zarr formats

[ghostiee-11]

What happens

Opening a STAC Item whose assets are not Zarr / NetCDF / HDF5 / kerchunk-ref (e.g. a Cloud-Optimized GeoTIFF) crashes inside xarray's backend with an opaque AttributeError:

import pystac_client
import xarray as xr
import xpystac  # registers the 'stac' engine

client = pystac_client.Client.open('https://earth-search.aws.element84.com/v1')
item = next(client.search(collections=['naip'], max_items=1).items())

xr.open_dataset(item, engine='stac', chunks=None)
# AttributeError: 'NoneType' object has no attribute 'variables'

The NAIP item exposes:

• image: image/tiff; application=geotiff; profile=cloud-optimized (COG)
• metadata: application/xml

xpystac picks one, hands it to xarray, the COG backend returns None, and xarray's _protect_dataset_variables_inplace then dereferences dataset.variables on None.

Expected

xpystac should pre-validate the asset's media_type and fail with a clean message, e.g.:

ValueError: Asset 'image' has media_type 'image/tiff; profile=cloud-optimized' which xpystac cannot open; use stackstac or odc-stac for COG-only collections.

Why it matters

This makes most of Earth Search (Landsat, Sentinel, NAIP) unusable with xpystac without users digging through xarray's traceback. We worked around it in holoviz/lumen#1867 by tightening our own predicate (media_type is now authoritative; STAC role hints fall back), but the friendly error belongs in xpystac.

Suggested fix

In xpystac.core where the asset is selected, compare its media_type against the set xpystac actually dispatches on (Zarr, NetCDF, HDF5, kerchunk JSON ref). If it's not openable, raise a ValueError naming the observed media_type and pointing at stackstac / odc-stac for COG-only cases.

Environment

• xpystac 0.5.0
• xarray (latest)
• Python 3.13

[keewis]

there's a special case for COG at

xpystac/xpystac/core.py

Line 112 in 2c2cf36

if obj.media_type == pystac.MediaType.COG:

I think your problem is that pystac.MediaType.COG is defined as "image/tiff; application=geotiff; profile=cloud-optimized" while you're using "image/tiff; profile=cloud-optimized", so it doesn't get picked up.

It appears that at least for the STAC ecosystem the value of pystac.MediaType.COG is authoritative (opengeospatial/CloudOptimizedGeoTIFF#1, even though there was some disagreement about IANA rules).

That said, if certain STAC servers already use the uncommon media type it might be a good idea to be a bit more lenient and check against both.

Edit: but yeah, the error is not great

[ghostiee-11]

Thanks for the pointer, that explains it. NAIP advertises "image/tiff; profile=cloud-optimized" without the application=geotiff token, so the pystac.MediaType.COG equality check at core.py:112 slips and the asset reaches xr.open_dataset. Tolerating both forms (e.g. checking for the profile=cloud-optimized substring once the type starts with image/tiff) would catch NAIP and similar slightly-off catalogs while keeping the canonical match. Happy to open a PR if useful.

[keewis]

let's see what @jsignell thinks

[ghostiee-11]

Yupp..