metgenc appears to be interpreting .spo file as data footprint

[afitzgerrell]

I was just testing a real collection, SNEX23_CSU_GPR in dry-run mode. In the ini file, I've defined a path for premet and spatial files, and within the spatial file dir are 3 .spo files each defining 5 points—four plus the first coord pair repeated to close the gpoly.
I checked the ummg files output and they contained the following for the gpoly:

        "GPolygons": [
          {
            "Boundary": {
              "Points": [
                {
                  "Longitude": -147.59,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.51,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.5099,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.1449
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.145
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.152
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.1521
                },
                {
                  "Longitude": -147.5098,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.5099,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.51,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.59,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.5901,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.1522
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.1521
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.152
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.145
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.1449
                },
                {
                  "Longitude": -147.5902,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.5901,
                  "Latitude": 65.1448
                },
                {
                  "Longitude": -147.59,
                  "Latitude": 65.1448
                }

I edited the .ini file to add

[Spatial]
spatial_polygon_enabled = false

This is a simple and effective workaround that now gets metgenc use just the spo file contents:

"GPolygons": [
          {
            "Boundary": {
              "Points": [
                {
                  "Longitude": -147.59,
                  "Latitude": 65.152
                },
                {
                  "Longitude": -147.59,
                  "Latitude": 65.145
                },
                {
                  "Longitude": -147.51,
                  "Latitude": 65.145
                },
                {
                  "Longitude": -147.51,
                  "Latitude": 65.152
                },
                {
                  "Longitude": -147.59,
                  "Latitude": 65.152
                }

I fear I did a poor job of confirming issue #255. I'm really sorry!!😞 Actually after a few hours of letting my head clear I realized that igbth4 rely on .spatial, not. spo files…so I did test that specific issue reasonably well. It's still a bummer that this only just cropped up (but at least I feel a little better about myself! 😏).

[afitzgerrell]

@juliacollins I forgot to tag you. Since there's a workaround and you certainly have other work to move onto now, It's fine to let this go so your time on the DUCk Project can wrap up. I can file it as a PSS ticket, or whatever system will be used for bugs since DUCk is [almost] complete.

[juliacollins]

@afitzgerrell A new release candidate exists to deal with the excitement described in this issue: https://pypi.org/project/nsidc-metgenc/1.13.0rc0/. The logic should now be:

• .spo file content should be read as-is, reversed and checked for polygon closure, regardless of the setting of the spatial_polygon_enabled flag
• The spatial_polygon_enabled flag should still default to True if it's not explicitly set in the ini file.
• .spatial file content will always go through the polygon generation step, unless spatial_polygon_enabled is explicitly set to False in the ini file.
• Spatial data read from netcdf coordinate variables should never go through the polygon generation step -- it is instead thinned via code in the netcdf reader. We may want to change this in the future so that all spatial information is routed through the same polygon-generation logic, whether it comes from a .spatial file or is read from a granule data file.
• A collection granule spatial representation of CARTESIAN should throw an error in conjunction with .spo files.
• .spo files must have at least three points.
• In general, only two points are acceptable if the GSR is CARTESIAN
• In general, there must be only one or more than three points if the GSR is GEODETIC. (Note, there is a slight inconsistency in the spo file check for "at least three points" vs. the check in all other cases of "four or more points" for a polygon. We might want to make this clearer/consistent in the future.)

Note: I did not update the README to deal with the implications of the changes I note above. If you've updated the README to describe the workaround for spo files (as is necessary with v1.12.0), then I would prefer to let you modify it in the future once the workaround is no longer needed. I was worried I'd clobber your editing work.

[afitzgerrell]

@juliacollins I've tested this and it looks good! 🎉

• .spo file content should be read as-is, reversed and checked for polygon closure, regardless of the setting of the spatial_polygon_enabled flag
• The spatial_polygon_enabled flag should still default to True if it's not explicitly set in the ini file.
• .spatial file content will always go through the polygon generation step, unless spatial_polygon_enabled is explicitly set to False in the ini file (but will or won't be acted upon based on geometry rules).
• Spatial data read from netcdf coordinate variables should never go through the polygon generation step -- it is instead thinned via code in the netcdf reader.
• A collection granule spatial representation of CARTESIAN should throw an error in conjunction with .spo files.
• .spo files must have at least three points.
• In general, only two points are acceptable if the GSR is CARTESIAN
• In general, there must be only one or more than three points if the GSR is GEODETIC. (Note, there is a slight inconsistency in the spo file check for "at least three points" vs. the check in all other cases of "four or more points" for a polygon. We might want to make this clearer/consistent in the future.) --AGREED, I'll track an item to unify expectations to be consistently conveyed as: "polygons must comprise four or more points".

I'll take care of README.md updates as necessary!