Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

CoverageJSON Examples in OGC API - Coverages (and some feedback/questions)

Abierto
  • ¿Algo no está bien?
#227 3 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
json
Área
documentation

Línea de trabajo

Comienza con el Examples Annex enlazado y valida sus respuestas CoverageJSON en CoverageJSON Playground; después, lee el issue #216 para conocer el contexto de la dimensionalidad. Se considera terminado cuando se haya producido feedback acordado o cambios en la documentación que cubran los ejemplos y las preguntas sobre dimensiones, presión, ejes textuales y serialización binaria.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

@jonblower @chris-little @m-burgoyne

Dear all,

I've added an Examples Annex to OGC API - Coverages with several example responses using CoverageJSON.

I would very much appreciate if you could find the time to review these examples.
So far I've validated them with the Playground. The data for now is synthetic, though I hope to eventually have more realistic examples along with pretty images, especially if I can manage to implement CoverageJSON in our server. Please ignore the old media type as I've already fixed that (should be picked up in the next document auto-generation update).

What worked great

The "ranges" as they're called (in OGC API - Coverages we would call that a single range with multiple fields) is quite straight forward and simple.

The "parameters" definitions (in OGC API - Coverages we would call them the fields) are also straight forward and simple, with the semantic definitions and units which is great.

I like the idea of being able to reference things even after you've sliced away their dimensions with the different domain types. I've used it in an example response for Position Query.

Though I have not yet illustrated them (I should), the "bounds" seem well aligned with the concept of cell bounds in OGC API - Coverages, the boundsCoordinates defined in OGC API - Common - Part 2 (Section 8.2.2 Irregular Grids) in particular.

What is causing some struggles

  • Max 4D: It seems that at the moment CoverageJSON is limited to 4-dimensional grids. (EDIT: At least the "domainType": "Grid" is) Is that correct? That seems to be confirmed by #216 . I will comment on that issue, but from my perspective this limitation does not considerably help interoperability. Assuming support for additional dimensions is introduced, if each axis/dimension is well anchored to a clear semantic definition / standard variable. The common 1-4D use cases would keep working just as well as they always did. Perhaps a separate requirements class for >4D grid would address this.
  • Fixed axis names: Somewhat related, I realized that I need to name the axes x, y, z and t. Again if each axis is clearly mapped to a semantic definition / standard variable, mandating these specific axis names should not be necessary, and not doing so would be much more flexible and extensible. We could have reflected the exact names used for referencing axes in OGC API - Coverages (e.g., Lat, Lon, time, pressure). Luckily, we recommend the definition of aliases which mostly match with those axis names.
  • Pressure as parametric (not vertical): There is one notable mismatch which is pressure levels. We are forced to store the pressure levels in z. As Roger Lott mentioned previously: pressure levels from a surface would be referenced to a parametric CRS. Vertical CRS now is explicitly a geometric coordinate system in the earth's gravity vector. See the discussion in https://github.com/opengeospatial/NamingAuthority/issues/228 where I attempted to make progress towards a parametric CRS for pressure levels, but eventually in OGC API - Common / Coverages we abandoned the idea of a "CRS" for non-spatial dimensions in favor of a simple ad-hoc semantic definition. I've used "type": "CoordinateSystem" for describing this pressure z axis (see this example), hoping that is OK practice rather than calling it a Vertical CRS.
  • Textual dimensions: I could not figure out how to properly define a non-numeric textual dimension, such as a category or taxonomy. Please see this example where I've resorted to "z": { "values": [ 0.0, 1.0 ] }, and then at the same level as "axes":, "zAxisText:values": [ "Gadus morhua", "Clupea harengus" ], to describe Atlantic Cod = 0, Atlantic Herring = 1. I would much welcome feedback if there is a better way to do this, or for improved capabilities in a future version to deal with such scenarios.

Binary CovJSON?

I am a big fan of Universal Binary JSON.
In fact if I had more time on my hands, I would probably be pushing more for it to become an OGC Community Standard.
Given that the majority of the coverage data is inside the NdArrays, and UBJSON has optimized array serialization, the binary payload would be very optimal. It's also quite easy to start playing with UBJSON with several packages like py-ubjson and @shelacek/ubjson (for NPM Node & Web) available to effortlessly convert between JSON and UBJSON.

I am curious whether any of you has previously experimented with UBJSON, or with other JSON binary serialization (e.g., CBOR) for CoverageJSON?

Thank you very much in advance for any help you can provide reviewing these examples or considering making the standard more flexible!

Lenguaje dominante
HTML
Estrellas
15
Forks
9
Merge medio
6 h 1 min
PR fusionados (30 d)
3

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opengeospatial/CoverageJSON

Todos los issues de opengeospatial/CoverageJSON

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.