Enhancing PLSS2LL and BLM API tools from sharpshootR

[brownag]

We have discussed the possibility of moving webservice-based tools from sharpshootR to soilDB.

I am thinking that we could create an enhanced-usability version of PLSS2LL to supersede the sharpshootR version (which does not need to be removed any time soon or ever necessarily, but could be deprecated and mention soilDB)

I have been working a lot with PLSS locations that cannot be fully resolved to quarter-quarter section via the BLM API used in sharpshootR::PLSS2LL().

My work flow for these involves dropping quarter-quarter, and in some cases even dropping section, in order to get some sort of location for the points. Even locating a point to a township is helpful if the more precise locations fail, as I am still doing manual customization of the location before import into the database. Township is a better first approximation than nothing, and generally the point can be well located based on more precise description and narrative.

I propose that a new version of PLSS2LL() builds in the option to re-trying inputs at several levels, essentially calling PLSS2LL several times on (ideally) increasingly small sets of points at increasingly broad resolution. The length of resulting PLSS ID is indicative of the lower precision, but could also add a field to indicate whether the point is a section center, QQ-center, township center, etc.

@dylanbeaudette @jskovlin, thoughts?

[jskovlin]

I think that would be a great idea. So far we've mostly set those functions up to be called in a modular fashion as needed. However, I have encountered workflows similar to what you found, Andrew. Where you need to test for a certain level of precision and then back out from there.

Agreed, a location (whatever precision) is still more useful than no location and there is definitely utility in those lower precision locations. With the differing types of sectional areas (protracted and unprotracted blocks) and the irregularities in the PLSS grid you can end up iterating many times to get derived locations. I think that options for retrying inputs could help with automating the tasks and giving the function great utility to automate the workflows we've encountered in using it.

I think that some tests for PLSS description validity and standardization (input prep type helper functions) might be useful as well. Take a pile of PLSS descriptions as entered - test which ones might have issues or be suspect. Data entry is frought with potential errors in this process. Missing values, typos, illogical formats/values, non-standard abreviation, parsing for distance measures from corners, etc - many different potential issues with the input data depending on where it is coming from.

Another need is expanded and updated tutorials on these demonstrating more in the way of a common workflow others could apply to their data.

[brownag]

Great points Jay. I think these tools are great to have as modular pieces--and probably that lower-level access can/should be preserved

But to your the point of expanding/demonstrating these tools for others I think the core/common operations could be simplified a bit. It is a lot of NA/table wrangling to run the three or more iterations of PLSS2LL and stitch it back together so it matches data.frame you started with. And that is assuming you are starting with consistent formatPLSS() output which is not easy to achieve.

I have been working with a variety of sources--but these days mostly fairly "standardized" ones such as those associated with TUD descriptions in manuscripts. I feel there will always be need for manual customization when working with historical sources, my process is not fully generalized yet, but I have a very similar stack of code running on 6 different SSAs right now.

I think a few more features could be added to enhance formatPLSS() and also make it check protracted and unprotracted block PLSSIDs better.