feat: init datatree support - #45
Conversation
|
@ljstrnadiii is attempting to deploy a commit to the carbonplan Team on Vercel. A member of the Team first needs to authorize it. |
video.mov |
|
one usecase I imagine this serving is UTM CRSes. But those are likely to have at least a tiny bit of overlap or buffering. What will happen in this case? |
| /** | ||
| * CRS resolver for missing proj4 definitions. | ||
| * - `true` (default behavior when omitted): try online EPSG lookup (https://epsg.io/<code>.proj4) | ||
| * - `false`: disable online lookup fallback | ||
| * - function: custom resolver callback | ||
| */ | ||
| resolveProj4?: boolean | ResolveProj4 |
There was a problem hiding this comment.
is there a way to bundle these into the package? In java we use a geotools extension: https://docs.geotools.org/stable/userguide/library/referencing/extension.html
arbitrary site access is not ideal.
There was a problem hiding this comment.
Kyle Barron just published a sweet and relatively small package of codes that I've been wondering if we should try implementing here! https://developmentseed.org/deck.gl-raster/api/epsg/
There was a problem hiding this comment.
Will update to use this tomorrow
| } | ||
|
|
||
| /** Describes a child dataset discovered within a datatree root. */ | ||
| export interface DatasetDescriptor { |
There was a problem hiding this comment.
its it ok to assume the child has the same CRS?
| @@ -0,0 +1,4 @@ | |||
| declare module 'wkt-parser' { | |||
There was a problem hiding this comment.
pardon my ignorance. Are we supposed to commit these ".d.ts" files?
| // Use first child store for shared dimension metadata in layer-level state. | ||
| this.zarrStore = this.datatreeStores[0] | ||
| rootStore.cleanup() | ||
|
|
||
| // Use first store for shared metadata (dimensions, fill_value, etc.) | ||
| const firstDesc = this.datatreeStores[0].describe() |
There was a problem hiding this comment.
I worry about this kind of assumed sharing of information across stores in a tree
| const EPSG_AUTHORITY_REGEX = /AUTHORITY\["EPSG","(\d+)"\]/g | ||
| const PROJ4_EXTENSION_REGEX = /EXTENSION\["PROJ4","([^"]+)"\]/ |
There was a problem hiding this comment.
I've been doing the same thing but im not sure if its ok to parse CRS WKT with regex. @paleolimbot ideas?
There was a problem hiding this comment.
I think there's theoretically whitespace allowed between the tokens but other than that I think it it would be unlikely to pick up some other portion of the CRS string.
4 participants
Summary
Closes #44
👋 I wanted to give this a shot and definitely used AI a lot for this. Happy to keep this in draft as a point of discussion or take any guidance if you are amenable to these changes!
[AI-based Description Below]
This PR adds first-pass datatree support to
zarr-layerand improves CRS/proj4 handling for datasets that don’t provide a complete projection definition inline.What Changed
ZarrStore.discoverDatasets(...)finds child groups containing the target variable.ZarrLayer:ZarrStore+ mode per discovered child dataset.resolveProj4option (true | false | callback) in public types/options.proj:*andspatial_refmetadata (including WKT parsing).wkt-parsertype declaration.resolveProj4option docs.multiscaleslayout metadata is present in root consolidated metadata.Assumptions / Current Constraints
scale_factor/add_offsetare assumed consistent across child datasets.crs/proj4/boundsoverrides are ignored so each child resolves its own spatial metadata.Validation
npm run typechecknpm run build