Replies: 2 comments 13 replies
-
|
An advantage of the second option would be addressing a common pain point for beginner users who regularly assume that |
Beta Was this translation helpful? Give feedback.
-
|
I think all of these are good ideas. Something I really like coming back to I also think that auto-guessing the output CRS is a fantastic usability win. I think it's not a terrible idea to drive the whole query API off WGS84... though I am probably not thinking of a bunch of use cases. Regardless, having output crs as |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Issue
Recently,
odc.stac.load()has diverged fromdatacube.load()in several small but important ways. These include updates to several frequently used parameters:dask_chunks->chunks(consistent withrioxarray)group_by->groupby(consistent withpandas,xarray)output_crs- >crs(as STAC loading has no need for separate query and load CRSs)alignwithanchor(with slightly different functionality; further discussion in Datacube 1.9 and 2.0 discussion #1529)And added and improved functionality:
geoboxas a new alias forlikebboxparamgeopolygonto be more flexible and work ongeopandasandshapelyobjectsThese changes are great, but they do increase friction between switching between
datacubeandodc-stac, as users need to remember different params to achieve the same end goal (loading a time series of data intoxarrayformat). This pain point is particularly significant asdatacube.loadandodc.stac.loadare two of the primary entry points to the ODC ecosystem for many of our downstream users.Proposal
I would like to propose that in Datacube 2.0 we aim for full consistency (or as close as we can get to it) between data loading parameters shared between
datacube-coreandodc-stac. This would have the following benefits:odc.geowhere possible)The changes made in
odc-staclisted above all make sense to me, so I would suggest that we adopt them directly indatacube-corein 2.0. This would mean adding deprecation warnings to current parameters (group_by,dask_chunksetc) in 1.9 so that users have enough time to transition to the new approaches for loading data.Challenges
Some of these params (e.g.
group_by,dask_chunksare used extensively through downstream code, so this would require users to make widespread changes to their applications when they upgrade to Datacube 2.0. However, my feeling is that a 2.0 upgrade is probably the best opportunity for a change like this, as breaking changes are likely to be a given.Would love to hear what people think about this proposal - I really think if we could achieve something like this it could make a big difference to usability across the whole ODC ecosystem. 🙂
Beta Was this translation helpful? Give feedback.
All reactions