Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Respecting cube dimension metadata can cause unexpected missing 'bands' dimension

未关闭
#959 3 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@soxofaan 已经在做这个了。

开始于 2026年10月21日。

评估

这个 Issue 还没有评估数据。

描述

bug STAC and load_stac

See:
https://forum.dataspace.copernicus.eu/t/cannot-access-gfm-band/5639

Loading a collection with this cube metadata:

"cube:dimensions": {
    "x": {
      "axis": "x",
      "type": "spatial",
      "extent": [
        -180,
        180
      ]
    },
    "y": {
      "axis": "y",
      "type": "spatial",
      "extent": [
        -90,
        90
      ]
    },
    "time": {
      "type": "temporal",
      "extent": [
        "2015-01-01T00:00:00Z",
        null
      ]
    }
  },

Contradicting with item_assets metadata, from which we can clearly derive that there's multiple data assets, and thus multiple 'bands':

"item_assets": {
   "advisory_flags": {
     "type": "image/tiff; application=geotiff; profile=cloud-optimized",
     "roles": [
       "data"
     ],
     "title": "GFM Advisory Flags",
     "description": "GFM Advisory Flags"
   },
   "dlr_likelihood": {
     "type": "image/tiff; application=geotiff; profile=cloud-optimized",
     "roles": [
       "data"
     ],
     "title": "GFM Likelihood (Intermediate output - DLR algorithm)",
     "description": "GFM Likelihood (Intermediate output - DLR algorithm)"
   },
   "exclusion_mask": {
     "type": "image/tiff; application=geotiff; profile=cloud-optimized",
     "roles": [
       "data"
     ],
     "title": "GFM Exclusion Mask (Final output - Ensemble algorithm)",
     "description": "GFM Exclusion Mask (Final output - Ensemble algorithm)"
   },
   "tuw_likelihood": {
     "type": "image/tiff; application=geotiff; profile=cloud-optimized",
     "roles": [
       "data"
     ],
     "title": "GFM Uncertainties (Intermediate output - TUW algorithm)",
     "description": "GFM Uncertainties (Intermediate output - TUW algorithm)"
   },

This is caused by this recently merged PR:
https://github.com/Open-EO/openeo-python-client/pull/867
@suriyahgit @clausmichele : in general, even if you could argue that the metadata is 'wrong', it would be better if the python client is smart enough to detect such contradictions, and avoid breaking. Is a short term solution possible?

主要语言
Python
星标
219
派生
58
平均合并
1 天 2 小时
30 天内合并 PR
8

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

Open-EO/openeo-python-client 的其他 Issue

查看 Open-EO/openeo-python-client 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。