You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2 years later: this should live in an independent package (time series analysis is not specific to DEMs), I think our efforts should now focus on https://github.com/friedrichknuth/gtsa.
However, it would be good to have a way somehow to "store" the best GP parameters specific to DEMs for easy user applications... GTSA could have a dem submodule storing those, or should it be called by xDEM and exemplified to do that? What do you think @friedrichknuth?
@rhugonnet thanks for the pointer to GTSA! It would be fantastic to have more hands on deck with this effort. I am also happy to transfer the repo to a broader organization when exposure/momentum builds and we feel the time is right.
With regards to storing DEM specific GP parameters - it is a good question and I'm not sure yet 🤔 I think a submodule in GTSA might make most sense since the parameters will be primarily related to time series analysis and avoiding dependencies is generally beneficial.
I envision a submodule for GP, then perhaps a class within that provides parameters for DEMs and subclasses for different earth surface types. Right now the primary use cases for GTSA will be DEM related, but there is potential for stacking and analyzing other raster datasets. If GP is the right tool for these products then they could receive their own class and subclasses within the GP module.
These are my preliminary thoughts but I'm open to whatever makes most sense!
I agree, a "thematic" submodule in GTSA makes the most sense for storing DEM parameters!
We might end up doing the same in xDEM for things specific to glacier, snow, geomorpho applications... right now we focused on things that were generic to DEMs.
For the time series analysis tools, it might be worth to have a look at what they recently added in GeoWombat (also based on dask/xarray) and how they organized it: https://geowombat.readthedocs.io/en/latest/gpu.html.
It could also be good to drop them a message to coordinate with GTSA, I already did the same on Xarray accessors for geoutils/DEM, with discussions in Xarray/Rioxarray/GeoWombat etc (#392, GlacioHack/geoutils#383) (it's fine on the Rioxarray/Xarray side, so I'm starting on it 😉!)
Existing work here: https://github.com/iamdonovan/pyddem/blob/master/pyddem/fit_tools.py#L2093
To scale GP application matricially, kernel learning automated methods, need to add methods implemented in: https://gpytorch.ai/
The text was updated successfully, but these errors were encountered: