home / github / issue_comments

Menu
  • GraphQL API
  • Search all tables

issue_comments: 790954807

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions performed_via_github_app issue
https://github.com/pydata/xarray/pull/4979#issuecomment-790954807 https://api.github.com/repos/pydata/xarray/issues/4979 790954807 MDEyOklzc3VlQ29tbWVudDc5MDk1NDgwNw== 1217238 2021-03-04T21:26:21Z 2021-03-04T21:26:21Z MEMBER

A major advantage is that using a custom index, there's no need to encapsulate a Dataset/DataArray into a higher level structure (e.g., xgcm.Grid) and there would be more control on how it is propagated from one xarray object to another compared to an attribute or via a "stateful" accessor (e.g., crs)

I agree, this would be really nice.

One challenge is that often it is not advisable to explicitly build the coordinate arrays that correspond to such grids For example, consider a satellite image: 2D lat/lon arrays could be as expensive to store as the image itself, even though the values can be computed on the fly with very cheap arithmetic.

To fill this gap, we need first-class support for custom lazy arrays in xarray. If you read the documentation for the backend refactor (https://github.com/pydata/xarray/pull/4810), you'll see that we do have a minimal version of this internally in the form of core.indexing.LazilyIndexedArray. Ideally we would not only expose this functionality publicly, but would even factor it out into a separate lazy "duck array" library that could be used independently of xarray.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  819062172
Powered by Datasette · Queries took 0.429ms · About: xarray-datasette