afitzgerrell
commented
1 month ago The DUCk-Ops meeting of 18 July 2024 revealed that CMR is where ingest [presumably] fails. I saw no evidence of this from reading the CMR Data Producer User Guide gpolygon rules.
I spoke with Chris, and regardless of where this idea that CMR ingest of the metadata will fail, Chris said he will have his team test the first file provided to us by the DPT which was a tile that crossed the anti-meridian. I will create umm-g and cnm files for it and hand that trifecta to the NSIDC Cumulus team via slack.
They should be testing the DPT mock-ups in a couple of weeks. They will provide error messages if ingest of this granule fails, while the other, non-antimeridian crossing granule ingests successfully. I'll see if I can resolve the errors with simple tweaks that follow rules which can be documented. If I can't fix it, I'll file a trouble ticket (TT) with CMR to document the tests and issues, and let them tell me why it doesn't ingest.
Background: Due to the polar nature of many NSIDC data sets, Geodetic GPolygon was frequently used for ECS/CMR ingest to best represent data spatial extent. It was the only area-type spatial representation that CMR allowed to cross the Earth's poles and International Date Line (referred to simply as 'date line' hereafter) as CMR doesn't allow Cartesian bounding rectangles to span either Earth's poles or the date line.
Cumulus Problem:
No area type granule spatial representation is allowed to span the date line(apparently? confirm this is accurate UPDATE: this is NOT accurate!!).The expectation we're dealing with presently is that a date line-crossing granule's spatial extent must be divided into two or more GPolygons situated on both sides of the International Date Line (or poles? I also currently don't know if pole crossings are disallowed in Cumulus or if just date line crossings are).In the case of data line-crossing data, the onus will lie on someone* to define data extent in granule metadata files as coordinates accounting for its total extent, but divided amongst two or more GPolygons that abut one another along the date line.*The question: who is this someone?- Is it new-metgen that should handle this?- Is it to be handled by Ops or the data producer via input files (to new-metgen as is currently done for existing-metgen) for spatial representation?- Is Cumulus ingest going to handle appropriately dividing a single GPolygon as necessary to represent the data extent as multiple GPolygons?- - Is this already happening during Cumulus ingest?In summary: Geodetic GPolygons adhere to the CMR rules of the Geodetic Coordinate System, (from https://wiki.earthdata.nasa.gov/pages/viewpage.action?spaceKey=ED&title=CMR+Data+Partner+User+Guide#CMRDataPartnerUserGuide-CoordinateSystems) where: The Geodetic coordinate systems are angular coordinates (longitude and latitude) and are closely related to spherical polar coordinates. They are defined relative to a particular Earth geodetic datum. The CMR implementation of the Geodetic coordinate system follows OGC standards, which are defined at https://www.opengeospatial.org/. The World Geodetic System 84 (WGS 84) is the supported geodetic system. Please be aware of the following geodetic coordinate system constraints: