Implement Validation Checks for COGs

[srizvi-NASA]

In the future, we plan to use the output of net3cog (the NetCDF to COG converter) with the HyBIG backend service.

To ensure compatibility with the HyBIG backend service, I propose implementing validation checks at the end of the NetCDF to COG conversion process. These checks would verify if the converted COG meets the following criteria:

1. CRS Definition: The COG must possess a valid Coordinate Reference System (CRS) definition that is recognized by rioxarray's crs attribute.
2. Number of Bands: The COG should have a band count (accessible via rio.count) of either 1, 3, or 4. This restriction might be due to specific requirements of the HyBIG service or limitations in the conversion process.
3. In addition to these two initial checks, consider including other validations to guarantee a correct and complete conversion. These could include range checks (e.g., verifying data values fall within a valid range).

By incorporating these validation checks as a separate function at the end of the conversion program, we can ensure the generated COGs are compatible with the HyBIG backend service and potentially identify any conversion issues early on.

[flamingbear]

Number of Bands: The COG should have a band count (accessible via rio.count) of either 1, 3, or 4. This restriction might be due to specific requirements of the HyBIG service or limitations in the conversion process.

This is definitely a design decision I mad for HyBIG. If there's on band, we can color the values either by a palette or grey scale. If there's three bands it's presumed to be RGB and 4 implies RGBA. If there's a valid/common way that a two-band (or 5+ band) image is visualized I wasn't aware of it when I wrote HyBIG. Is that something I should be concerned about?

[srizvi-NASA]

I've added a util to check for what will be needed by HyBIG as far as a cog is concern. This can be updated as we develop HyBIG.