Is the bounding box/geometry always constant?

[gadomski]

All items created by this package have the same bounding box (and therefore geometry):

goes-glm/src/stactools/goes_glm/stac.py

Line 191 in f96294f

bbox = constants.BBOXES[0]

Is this true? I know for GOES ABI data, there are different image scales (e.g. meso-scale, full disk, and CONUS). The GLM is a different instrument so probably works differently, but I just wanted to check that all GLM netCDF items should have a bounding box that encompasses the full disk.

Also, is it the same bounding box regardless of whether the data are from -16 or -17?

[m-mohr]

Not 100% sure, that's why there's also a todo in the code. As far as I can tell from the examples that I have access to, yes it is always full disk. But the amount of examples that I have might not give me a full view on things. Probably to be confirmed by NOAA.

Note to self: If it is always full disk, I should set the corresponding field from goes extension.

Note: This is partially a duplicate of #9.

[m-mohr]

There are a number of issues here:

1. ABI and GLM geometries are not equal, GLM is slightly smaller and as such I'm not sure we can call it FULL DISK. I removed the goes:image-type flag for now. How is FULL DISK defined @gadomski ?
2. Indeed the GLM bboxes/geometries for West and East are different. I changed that in the code to different constants. I'm not reading the bbox/geometry from the files as it seems that there's no straighforward way of doing this.
3. GLM geometry and bbox for G17 (West) cross the antimeridian. As such I had to check how STAC wants this to be handled. It seems according to the GeoJSON spec I should split the Polygon, so I did that: Due to that, I also specified multiple extents in the spatial extent array of the Collection. The Collection union extent (first array element) is likely to cause problems in some tooling due to the antimeridian crossing. See Bounding box for some collections invalid? microsoft/PlanetaryComputerDataCatalog#327 (comment) for a related issue/discussion.
4. According to https://github.com/blaylockbk/goes2go#field-of-view there's a "circular" cut out in the geometry. This is not reflected in the geometry of this package as I can't find any official documentation about it. From looking at the goes2go code, it seems they also could not find it and base their work on private communication with NOAA. So not sure how to proceed here. Contect NOAA and ask for an official geometry for the products? @gadomski
5. (GOES-18/T is not reflected, as discussed.)

The corresponding commit for these changes is at 4914207 if you'd like to have a look.

[m-mohr]

Here's an example of the G17 Item that crosses the antimeridian:
https://radiantearth.github.io/stac-browser/#/external/raw.githubusercontent.com/stactools-packages/goes-glm/main/examples/item2.json
And here's the collection:
https://radiantearth.github.io/stac-browser/#/external/raw.githubusercontent.com/stactools-packages/goes-glm/main/examples/collection.json
Just so that you have a visual indication of how it's done, although STAC Browser doesn't show the spatial union extent.

[gadomski]

How is FULL DISK defined

It's an ABI definition (there's some text on this page: https://www.goes-r.gov/spacesegment/abi.html) so I agree that it isn't appropriate to use for the GLM data.

The Collection union extent (first array element) is likely to cause problems in some tooling due to the antimeridian crossing.

Agreed. We have a utility in stactools that can either split or "normalize" an antimeridian-crossing geometry, since (as you correctly point out) different tools do better with different formats. I think splitting for now is fine, and we can refine later if we need to change.

So not sure how to proceed here. Contect NOAA and ask for an official geometry for the products?

I'll take an action to chase this down on my side, but for now let's ignore the cutout in this package and come back and update later if needed.

[m-mohr]

NOAA can't provide anything that we could really use here so far.

GLM uses variable-pitch pixels, so the calcs get a bit tricky. There’s a diagram in an Export Controlled document that would help a math-savvy person. I'll keep looking for similar documentation in shareable documents.