Attendees:
Agenda:
- Review previous recommendations given to the GEDI science team
- Proposed feature matrix for GEDI_L1A
- Recommended CF-compliant metadata items (not critical to subsetter performance
Meeting Minutes
- Reviewed EED2 recommendations for L1A data modifications
- The EED2 development team will make the necessary changes to accommodate multiple coordinate sets within a group and multiple sets of data itesms referring to those coordinates.
- Reviewed a notional service matrix that was developed for ICESat-2 to provide examples of the type of services used in the ICESat-2 mission
- Formats requested from LpDAAC would initially include as least one of csv, ascii or shapefile
- At some point, Ken will demo the subsetter to the GEDI tag-up group at a future 4pm meeting
- L3/L4 data is expected around 10/1/19
- GEDI status review is on 8/16/19
In summary, of the 5 items mentioned in the EED2 recommendations (see below), all but item 2 were agreed for updates within the GEDI datasets. Item 2 is not being changed and will be accommodated as is by the EED2 development team.
Attachments
Previously distributed EED2 recommendations for L1A data modifications -
(Note that we removed all but one of the /BEAMXXXX groups as a simplification since they all look the same and we assume that the updates necessary for one such group would apply equally to the others).
- Collection Identification - shortName and VersionId
- We modified the data file to create the attribute where we needed it to be.
- However, we concede either is a good enough location and will likely modify the subsetter to look for either. Thus - no changes to GEDI product is recommended or required.
- Subsetter requires this to differentiate various special cases
- Exists in two places in ICESat-2 Data Files - GEDI used one (root level attribute), we expect it in the other (METADATA group, DatasetIdentification sub-group).
- Multiple different coordinate sets and science datasets that reference those different coordinates, within a group level. E.g., /BEAMXXXX/geolocation has three different lat_xxx and lon_xxx values, and three different sets of science data that refers to these different coordinates.
- We created three subgroups to isolate these sets of data.
- This is currently a required change as our subsetter expects all of the science data in a group to use the same set of coordinates. It also seems like a good organizational update for the data.
- It is possible we could update the subsetter to not process the data in a group uniformly and only follow the coordinate references as provided. However, it seems like best practice to implement distinct grouping for each coordinate set. We are a bit reluctant to make this change.
- Delta-Time vs. Master_Int and Master_Fraction as coordinate references.
- Create a coordinate reference, e.g. to ../../geolocation/delta-time - across group levels, across hierarchy
- Our software does not support across group or across hierarchy references, though we are willing to consider this change
- We do, however, support up-level references. Your original product had these under e.g., TX_PROCESSING for Master_Int and Master_Fraction. We did the same with delta_time, functioning correctly.
- Delta-Time could be copied to each group that references it
- We did not explicitly do this, though it seems an obvious choice, and presents no implementation challenges.
- A soft or hard link dataset can carry a reference to this data.
- We created a soft-link for several alternate location of delta_time, with geolocation/bin/delta_time as the only populated dataset and the others just references
- e.g. geolocation/lastbin, geolocation/spacecraft, and /BEAMXXXX/delta_time
- Our software requires a delta time dataset as coordinate reference vs. Master_Int and Master_fraction datasets; Delta time is available in the data product, though not co-located with the science data in all cases.
- There are three choices for fixing this. Either -
- Coordinates with coordinate references
- /BEAMXXXX/geolocation/longitude_bin0 is using latitude_lastbin as its coordinate reference,
while /BEAMXXXX/geolocation/latitude_bin0 is using longitude_bin0 as its coordinate reference. It is not clear what the references are intended to be, but these seem to be cross-wired a bit. - We assume that e.g., the time and lat/lon datasets will all get subsetted at the same time as the others are when a spatial or temporal constraint is applied. Thus, I think the proper coordinate references should be “delta_time <lat> <lon>”. We applied this update as a recommended setting, though it is implicit in our software.
- Delta Time should have units of “seconds since <epoch>”, which is the CF convention. Our software requires this to properly assess time for temporal subsetting. We made this update using the epoch value of “2018-01-01”
Overview
Content Tools