.summarizeSoilTemperature()

[dylanbeaudette]

TODO

• re-name and export this and related functions
• add "gam" method for estimating MAST, MSST, MWST

Notes

This function currently estimates MAST, MSST, MWST by taking the mean (sensor value) by sensor / julian day. It would be nice to have an alternate method based on fitting a smooth function via GAM with periodic smoother--if there are enough data to support it. Perhaps smooth function with sensor/julian day mean as a fall back.

For example:

[brownag]

This function is exported as summarizeSoilTemperature(). Also estimateSTR(), and supporting functions month2season(), waterYearDay(). And plotting function STRplot() in soilDB.

sharpshootR has estimateSoilMoistureState(), plotAvailableWater(), plotWB(), etc.

If summarizeSoilTemperature() were to become more complex (e.g. applying a GAM) I wonder whether we are going beyond the scope of soilDB a little bit. Though it is a good and important idea to have that functionality--as data gaps really cause issues for determining soil climate related criteria.

Since there are several other packages currently being developed in this realm I wonder whether there is another place to put further work on these things.

I don't really have strong opinions either way, but I feel like we could probably make a more harmonious interface to our various soil climate related tools. SoilTaxonomy or sharpshootR could be good existing places to put things, as SMR/STR are clearly related to taxonomy, and sharpshootR already provides some climate modelling/visualization interfaces. STRplot() feels a little out of place as the only plot/graphics function currently exported from soilDB.

I wonder if a relatively low dependency {SoilClimate} package would be useful for abstracting out these types of function, allowing them to be more easily shared between soilDB, SoilTaxonomy, sharpshootR, rnewhall, rosettaPTF, jNSMR etc.

[dylanbeaudette]

This is a good idea. I think that there are enough functions / functionality spread across soilDB and sharpshootR to warrant a new package targeted to soil / near surface climate work. Agreed that summarizeSoilTemperature(), estimateSTR(), month2season(), and waterYearDay(), and STRplot() should all be moved out of soilDB.

Also in sharpshootR that can be moved to a new package:

• dailyWB()
• plotWB() and plotWB_lines()
• estimateSoilMoistureState()
• FFD() and FFDplot()
• moistureStateProportions() and moistureStateThreshold()
• PCP_plot()
• prepare_SSURGO_hydro_data()
• prepareDailyClimateData()

Some or all of those are good candidates.

I'm on the fence about functions for "getting" data such as fetchSCAN() (soilDB) and CDECquery() (sharpshootR).

[brownag]

I would agree that those could make a great new package. I think soilDB should handle functions for getting data. Possibly some functions from sharpshootR ought to be brought into soilDB in this reshuffling. The functions involving web services are a pain in the butt and might be best kept under one roof.

Another area where this new soil climate package could focus is on NA-filling and related data quality measures e.g. #27

[dylanbeaudette]

OK, so maybe put CDEC stuff into soilDB? I have no problems shuffling things around, esp. those functions from sharpshootR.

[brownag]

It would be nice to make moves on restructuring some of the namespaces around this topic.

Could soilDB adopt the web service related tools from sharpshootR? i.e. CDEC, LL2PLSS, PLSS2LL, ...?

What would a soil climate or soil taxonomy (with climate-related tools) package/namespace look like? What do we need in SoilTaxonomy to make that happen (if anything)?

[dylanbeaudette]

Agreed. Moving the www service stuff into soilDB seems like a good idea, happy to help.

As for the soil climate / taxonomy packages:

• new package (soilClimate ?) for soil climate data / processing / modeling, geared towards our internal uses and Soil Taxonomy (STR, SMR)
• FFD and related
• water balance data prep and modeling
• others outlined above

I'm happy to discuss, but seems like the SoilTaxonomy package should remain close to its current goals: making ST simpler to navigate, formative elements, parsing, and eventually (?) navigation of the 'Keys.