feat: define separate collections for each product, define GRIB layers with byte ranges in 'grib:layers' asset metadata

[hrodmn]

After a lengthy discussion in #1 and #3, this is the approach that I have settled on for representing the HRRR data in STAC metadata to start. The grib:layers property for each .grib asset will enable applications to construct coherent xarray datasets from an Item or ItemCollection.

Check out the examples/ folder for example collection and item metadata.

STAC metadata structure

• One collection per region x product combination
  • regions: conus and alaska
  • products: sfc, prs, nat, and subh
• Collection-level datacube extension metadata
• One item per GRIB file in the archive
• Two assets per item:
  • "grib": actual file containing data
  • "index": .grib2.idx sidecar file with layer-level metadata
• Within each "grib" asset, a grib:layers property with details about each layer in the .grib2 file
  • details include human-readable description, units, and access information like start_byte, byte_size.
  • this is something that could be generalized across all GRIB datasets but would need to study the GRIB metadata specification in more detail to do it properly
  • storing the byte ranges in STAC would make them accessible to any application that can read STAC metadata without needing to load the .idx files again.

Advantages

• Applications can make use of the grib:layers property from the grib asset in each item to create layer-specific dsns that the GDAL GRIB driver can read
  • using /vsisubfile: /vsisubfile/{layer['start_byte']}_{layer['byte_size']},/vsicurl/{grib_asset.href}
  • or href://: `vrt:///vsicurl/{grib_asset.href}?bands={layer['grib_message']}
• Splitting the archive up by region and product makes it possible to define coherent collection-level datacube metadata which should improve the accessibility of the many layers of the dataset for exploratory applications and new users

Disadvantages

• Storing the byte ranges in STAC metadata is not a typical pattern
  • Creates a redundant copy of information that is already in the .idx file
  • Storing layer-level information in json for each item is inefficient
• More collections might make it more difficult for new users to become familiar with the contents.

Considerations

• The discussion in /vsisubfile reads GRIB2 files inconsistently OSGeo/gdal#10214 shows that GDAL can read subsets of data using the vrt syntax with the band index of interest. If we want to leave the byte range data out of the STAC metadata and think harder about whether or not that belongs in STAC, that would be fine. We would still need some layer-level metadata but the byte ranges are not absolutely necessary.

[hrodmn]

@abarciauskas-bgse @vincentsarago the render parameters are not complete because we will need to specify the layer-specific dsn rather than specify a STAC asset.