Provide more grid fields

[fmigneault]

Description

The readme (https://github.com/stac-extensions/grid?tab=readme-ov-file#additional-field-information) indicates many fields for each example (format string, example, components, products and reference).

Can those be added explicitly to the JSON schema?

Currently, the schema explicitly forbids grid:... beside grid:code, which forces adding these properties as general metadata fields without a relevant prefix. This makes it hard for clients to know what to parse to find relevant grid items.

Furthermore, grids often come with nesting considerations (coarser/finer representations). Could there be additional fields that reflect these references. For example, a grid:parents, grid:children and grid:neighbors that could reflect other STAC items that contains/are-contained-within/lives-next-to the current item being described.

Example result

Collection

{
  "grid:format": "custom-grid_L{level}.{id}",
  "grid:components": ["level", "id"],
  "grid:reference": "<uri-to-custom-grid>"
}

Item

note: each ./custom-grid_[...] could be an {"href": "...", "type": "..."} instead.

{
  "grid:code": "custom-grid_L2.5",
  "grid:components": {
    "level": 2,
    "id": 5
  },
  "grid:reference": "<uri-to-custom-grid>",
  "grid:parents": [
    "./custom-grid_L1.5.geojson"
  ],
  "grid:children": [
    "./custom-grid_L3.1.geojson",
    "./custom-grid_L3.2.geojson",
    "./custom-grid_L3.3.geojson",
    "./custom-grid_L3.4.geojson",
    "./custom-grid_L3.5.geojson"
  ],
  "grid:neighbors": [
    "./custom-grid_L2.1.geojson",
    "./custom-grid_L3.2.geojson",
    "./custom-grid_L3.3.geojson",
    "./custom-grid_L3.4.geojson"
  ]
}

[m-mohr]

This feels like a completely new extension to me as the complexity of the extension would explode. Could this evolve in a separate extension that is based/extends the grid extension?

The readme (https://github.com/stac-extensions/grid?tab=readme-ov-file#additional-field-information) indicates many fields for each example (format string, example, components, products and reference).

These are not fields right now, just certain criteria that describe a specific type of grid code in more detail.

[fmigneault]

Indeed, the "fields" are not actual schema fields at this time. My proposal is that, given those are listed for each of the examples, they might as well be available as optional fields in the schema.

It could work to have a separate extension dedicated to DGGS. It doesn't necessarily have to depend on grid since only one field applies, but it would make sense to have all (grid:code, dggs:code, other dggs:... properties) together within the Items.

However, I feel that given only grid:code is defined currently, there is room for expansion. Not only that, there is already an EASE-DGGS example, so it seems DGGS should really live within this same extension. It might be confusing for users why there are multiple "grid" extensions.

I think only the grid:code, grid:format (or grid:uriTemplate?) and grid:components are worth being "required" in a grid v2.0, since those actually provide the information of available ranges of the values to form valid URIs. This applies to any kind of "grid".

All other fields would be additional metadata that can be provided to help navigating between different grid elements, but would remain optional, since navigating the grid can be done using the grid:format and grid:components directly.