Add support for an additional explicit dimension in the CoverageJSON schema
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- json
- Domaine
- data
Piste de recherche
Commencez par examiner le schéma CoverageJSON actuel ainsi que le fichier joint extended_covjson_schema_example.json. Déterminez comment une dimension supplémentaire explicite telle que ensemble ou « e » doit être déclarée, y compris ses coordonnées et sa taille, tout en restant cohérente avec x, y, z et t ; le travail est terminé lorsque le schéma peut représenter directement ces dimensions au sein d’une coverage.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- HTML
- Étoiles
- 15
- Forks
- 9
- Merge moyen
- 6 h 1 min
- PR mergées (30 j)
- 3
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de opengeospatial/CoverageJSON
-
Difficulté 2/5 1-3 heures Accessibilité débutants 45/100
opengeospatial/CoverageJSON#233 ·
-
New CovJson LibraryOuverteImplementations
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
opengeospatial/CoverageJSON#229 · 3 commentaires ·
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
opengeospatial/CoverageJSON#227 · 3 commentaires · 1 réaction ·
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
opengeospatial/CoverageJSON#218 · 4 commentaires ·
-
V1.1
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 30/100
opengeospatial/CoverageJSON#207 · 3 commentaires ·
Toutes les issues de opengeospatial/CoverageJSON
Issues similaires
-
Drained trajectory arrays are overwritten when the sequence buffer is reusedPeut-être pris @sylvesterkaczmarek l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
google-deepmind/bsuite#56 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
schedule-review
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
daniezl/Hilltoppers#77 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
CliMA/ClimaArtifacts#184 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour