search

ncss-tech / soilReports

An R package that assists with the setup and operation of a collection of soil data summary, comparison, and evaluation reports. These reports are primarily used by USDA-NRCS soil scientists in both initial and update mapping.
15 stars 5 forks source link

consolidation / management / archival of genhz rules #52

Open dylanbeaudette opened 7 years ago

dylanbeaudette commented 7 years ago

Everyone does this differently and there is no long-term strategy that I am aware of. Some options:

  1. assign to pedon data in NASIS via component layer ID (clearly this has many shortcomings and can't be applied to component data)

  2. keep .R files around with a list of REGEX rules and associated labels

  3. create / curate a more complex data structure that we all have access to, is human readable, and easily compared across versions (sounds like something that can stored on github) that is applicable to "series-level" concepts or concepts that are close-enough to the soil series--started a related repository

... I'll move the rest of my ideas over to the new repository, but wanted to place-marker here because soilReports is where the application of these rules happens.

brownag commented 7 years ago

Personally, I'm putting in my two cents for option 3. Component layer ID is a nice place to store, but unable to keep track of progressive "correlations" due to it being one field and not a table unto itself.

Further, component layer ID becomes confounded when the same pedon record is supporting documentation for multiple components, especially if the modal pedons for those components have different horizonation. In an "ideal" world, I suppose all components range in characteristics would be derived from pedons found within that mapunit's extent (rather than e.g. an adjacent slope class), but at least in 630.... relying on comp layer id as a permanent record of correlation decisions is not really that feasible.

And while I do think its worth keeping track of component<->regex pattern rules, I don't think R files filled up with lists of regex patterns is really ideal for traversing these data. Cya in the other repo!