Altimetry ICESat-2 suggestions

[dshean]

Consider implications of using srt 0 instead of 3 for some SlideRule requests, esp near coasts or near glaciers - maybe don't use the ATL03 class filters
Confidence values in request - maybe try only high-confidence initially, and if counts are low, rerun. Or potentially run both, and see if they give the same answer. Can iterate on this.
At some point, we may want to swap in the SlideRule phoreal/atl08 processor for the current ATL06-SR processing for top-of-canopy, ground, etc. but using shorter segment lengths
May want to support YAPC classification
For some reason, the "pull" term sounds odd to me. Maybe avoid in function names if possible
Season definitions might require further discussion - are these just a single ~90 day filter around the stereo acquisition date, or is there an option to do this across all years in the mission?
In addition to a single or multi-beam along-track profile (with ATL03 and ATL06-SR points), consider an orthogonal cross-track profile across the full DEM (will have sparse ICESat-2 points and dense DEM points, but useful for comparing multiple ICESat-2 collections

[bpurinton]

Consider implications of using srt 0 instead of 3 for some SlideRule requests, esp near coasts or near glaciers - maybe don't use the ATL03 class filters
Confidence values in request - maybe try only high-confidence initially, and if counts are low, rerun. Or potentially run both, and see if they give the same answer. Can iterate on this.
At some point, we may want to swap in the SlideRule phoreal/atl08 processor for the current ATL06-SR processing for top-of-canopy, ground, etc. but using shorter segment lengths
May want to support YAPC classification

To all of these points, here is the related issue opened on SlideRule: SlideRuleEarth/sliderule#448

For now, I'm going to stick with my high_confidence, ground, canopy, and top_of_canopy selections as defined by the SR documentation.

Later, we can refine these selections, but as they are, the steps provide a decent diagnostic for checking DEM quality and alignment.

For some reason, the "pull" term sounds odd to me. Maybe avoid in function names if possible

How about request_? I think that accurately captures the purpose of such methods (we place API requests to SlideRule; a response is sent back in the form of a geodataframe)

I will update the names of such methods in my work on #59

Season definitions might require further discussion - are these just a single ~90 day filter around the stereo acquisition date, or is there an option to do this across all years in the mission?

There are three temporal filters I apply (and I retain the all-time unfiltered as well, for a total of four temporal options):

1. A +/- 15 day pad on either side of the scene collection date. I.e. a 30 day window. This is naive to any seasonal definitions, and is just a "closest in time" attempt.
2. A +/- 45 day pad on either side of the scene collection date. I.e. a 90 day window. This is naive to any seasonal definitions.
3. All time within the season of collection. Seasons defined as DJF, MAM, JJA, SON. I.e. If the scene was collected on March 15th, 2024, this temporal filter would select all ICESat points from all years in MAM.

In addition to a single or multi-beam along-track profile (with ATL03 and ATL06-SR points), consider an orthogonal cross-track profile across the full DEM (will have sparse ICESat-2 points and dense DEM points, but useful for comparing multiple ICESat-2 collections

I can work on this on. Sure.