Tom Augspurger

Thanks @joshmoore. > I definitely agree that this is a tricky (though critical) part of the bootstrapping[...] Sorry, I don't quite understand this set of questions and the "some" /...

>> (and so no duplication). > except the current definition would still have 2 keys for the same information even if the storage and/or retrieval has been optimized, right? That's...

> That a way to tune the metadata loading for different cases is a given, but I would hope we could also improve on it. Maybe, but I try not...

https://github.com/zarr-developers/zarr-specs/issues/316 has stuff on the extension side. Happy to discuss more there, but I don't think the limitations of Zarr's extension story should bear on this PR.

> (i.e., if we were under semver a minor release). The two paths I see are: I avoid semver conversations as a matter of course (aside from linking to https://hynek.me/articles/semver-will-not-save-you/),...

>> but the key thing here is this is backwards compatible. > (Per the zarr-python meeting) versioning is definitely an issue, but regardless, as things stand we also have to...

> immutability of the spec, lack of versioning, and untested extension mechanism makes even scoped changes nerve-wracking The changes here use the extension and change mechanism we have. Let's use...

> this should be a ZEP in order to gain wider endorsement and review, or (for the moment) should be a true extension not defined in the core metadata. FWIW,...

> My time to respond now is unfortunately limited since I'm getting to get on a bike for a week, Thanks, enjoy!

Thanks for the report. Looks like we just forgot to pass the `crs` through at https://github.com/geopandas/dask-geopandas/blob/33e2af89318173c4b3b403e5f3b430fd3fcf88db/dask_geopandas/expr.py#L912-L914. This diff seems to fix it ```diff diff --git a/dask_geopandas/core.py b/dask_geopandas/core.py index b448319..4ef455c 100644...