Add contents of "Ant_Grounded_DrainageSystem_Polygons.txt"

[maxrjones]

@espg would it be possible to commit the contents of "Ant_Grounded_DrainageSystem_Polygons.txt" used in the demo notebook or the source code for producing it? I'm assuming it's a subset from https://earth.gsfc.nasa.gov/sites/default/files/lab_cryo/data/polar_ice_altimetry/antarctic_and_greenland_drainage_systems/ant_full_drainagesystem_polygons.txt, but would want to check as I'm not super familiar with the data products.

[weiji14]

It should be that file. The demo code uses pd.read_csv, so you could probably just point at that URL and see if it gives you the same "Loaded 1,239,001 vertices across 27 basins" output.

[maxrjones]

It should be that file. The demo code uses pd.read_csv, so you could probably just point at that URL and see if it gives you the same "Loaded 1,239,001 vertices across 27 basins" output.

thanks, seems like I found a slightly different version ("Loaded 901,322 vertices across 27 basins"). The differences shouldn't matter though for the optimization exercise.

[weiji14]

Oh wait, try https://earth.gsfc.nasa.gov/sites/default/files/lab_cryo/data/polar_ice_altimetry/antarctic_and_greenland_drainage_systems/ant_grounded_drainagesystem_polygons.txt. You want the grounded ice portions (blue), not the ones with floating ice (orange).

Figure from https://earth.gsfc.nasa.gov/cryo/data/polar-altimetry/antarctic-and-greenland-drainage-systems

If you just care about aggregating (more) points over a larger area into a DGGS grid, then it shouldn't matter. But it will matter if you consider than ATL06 elevation points over ice shelves can be affected by tides moving the floating ice up and down 🙂

[espg]

Yes, those gsfc links are where the file comes from! The mortie library is getting pulled in as a dependency and also has a copy of the file committed in that repo (here in testing , since there are unit tests run against it)

[espg]

I can work on optimizing the point query portion to be more efficient, and also add in some additional unit tests to make sure it's not missing things on edge cases. The big thing that's most relevant to fix is the write location-- can we write directly to zarr, and how to harmonize so that the chunking solutions match on both the array object that's the write target and the worker process.

Would it be easiest to try and prototype this with a fixed output array that isn't in the morton / healpix space, but is just a regular polar stereographic grid? I'm going to adapt this for the smaller bedmap use case (also, related utility file) that Mickey has; that example will be small enough to run locally without calling to lambda, but large enough to still want to chunk outputs and (locally) tile the processing. We've already written a replacement for the how they grab the bedmap data, so it would be adapting these magg functions to also replace the aggregation portion.

I'll send an update with a link to a first pass at this on the aggregation part, but would love some ideas or guidance on how to think about writing the output to a single zarr xarray.