Hi Kyle, I think I mentioned this to you before, but I want to suggest adopting {arcgislayers}
as a backend for interacting with ESRI's AGOL. That package is going through some additional testing, but I believe it should reach a stable version in the next couple of weeks or month.
Benefits:
{arcgislayers}
is officially supported by ESRI. That's maybe not a great argument... but!{FedData}
that you would no longer have to maintain.Costs:
{arcgislayers}
is built around the idea of interacting with AGOL (upload, download, query, retrieve metadata, etc), so there's a risk of mission creep.Just to give an example of the trade-off here, {arcgislayers}
gives you the power to query AGOL and return a table without spatial data, which is nice for exploring data before figuring out what features to download. It also allows you to specify what attribute data you want to get. But right now, {FedData}
always returns all of the spatial and attribute data. My own feeling is that the benefits of filtering rows and selecting columns outweigh the potential risks, but a hardline should definitely be drawn there.
Also, get_nhd()
will require some special treatment since it returns a list. My guess is additional functions for retrieving individual components of NHD, so that uber function can be left alone.
What do you think?
If it helps, this is something I would be more than willing to invest some time. Least I can do since this package factors so heavily in all of my research.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4