Add support for an additional explicit dimension in the CoverageJSON schema
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 冷清
- 技術堆疊
- json
- 領域
- data
研究方向
首先檢視目前的 CoverageJSON schema，以及隨附的 extended_covjson_schema_example.json。確定應如何宣告一個明確的額外維度（例如 ensemble 或「e」），包括其座標和大小，同時與 x、y、z 和 t 保持一致；完成的標準是 schema 能夠在一個 coverage 內直接表示這些維度。
由索引模型根據 Issue 內容生成。
描述
There is currently a limitation in the CoverageJSON schema whereby certain logically independent axes cannot be modelled as first‑class dimensions within a single coverage. Instead, these cases are typically forced into the use of coverage collections.
This issue proposes adding support for an additional explicit dimension in the CoverageJSON schema, to allow such axes to be represented directly and consistently alongside existing dimensions (e.g. x, y, z, t).
A common and concrete example is ensemble data. Ensembles represent a dimension that users frequently need to subset across (e.g. selecting specific ensemble members, computing statistics across members, or visualising individual members).
From a user and client perspective, ensemble behaves like a true dimension:
- Users expect to subset, slice, or aggregate across ensemble members in the same way as they would across time or vertical levels.
- Clients often want to request a single ensemble member or a small subset of members efficiently.
- Downstream processing frequently treats ensemble as an axis over which operations are performed.
Modelling ensemble as a coverage collection rather than a dimension is inefficient and semantically awkward in this case:
- It requires clients to iterate over multiple coverages to perform what is conceptually a single subsetting operation.
- It complicates request syntax and client logic, especially for APIs that already support dimension‑based subsetting.
- It prevents clear expression of the full multidimensional structure of the data within a single coverage object.
An example of a proposed update to the CoverageJSON schema is attached to this issue. This example illustrates how an additional dimension 'e' (extra) could be declared explicitly within a single coverage, including its coordinates and size, while remaining consistent with the existing schema structure and conventions.
This change would improve expressiveness for multidimensional datasets, reduce client‑side complexity, and better align the schema with common usage patterns for ensemble and other similar data types.
- 主要語言
- HTML
- 星號
- 15
- 分支
- 9
- 平均合併
- 6 小時 1 分鐘
- 30 天內合併 PR
- 3
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
opengeospatial/CoverageJSON 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 45/100
opengeospatial/CoverageJSON#233 ·
-
Implementations
難度 5/5 一週以上 新手友好度 25/100
opengeospatial/CoverageJSON#229 · 3 則留言 ·
-
難度 5/5 一週以上 新手友好度 25/100
opengeospatial/CoverageJSON#227 · 3 則留言 · 1 個 reaction ·
-
enhancement
難度 5/5 一週以上 新手友好度 30/100
opengeospatial/CoverageJSON#218 · 4 則留言 ·
-
V1.1
難度 5/5 一週以上 新手友好度 30/100
opengeospatial/CoverageJSON#207 · 3 則留言 ·
查看 opengeospatial/CoverageJSON 的全部 Issue
相似的 Issue
-
IRIS reader: no-data velocity bins (DB_VEL, DB_VELC) returned as 0.0 m/s instead of NaN可能已有人在做 @syedhamidali 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 2 天內回覆
-
⚠ needs intervention document structure changed
難度 2/5 1-3 小時 新手友好度 72/100
-
automation models
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
bug good first issue med Properties small
難度 2/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100