Use arcgislayers as backend for ESRI's AGOL #109
Comments
|
I completely agree — the benefits outweigh the costs here. If you are willing to prototype something and submit a PR (or even just fork and share your repo with me), I think we can get this done. I could use the help!
My goals would be to add functionality to the api but not create any breaking changes at this point. We can talk about restructuring what functions return (e.g., `get_nhd()`) at a later juncture.
Thanks much for the offer!
Best,
Kyle
… On Jan 18, 2024, at 8:49 AM, Kenneth Blake Vernon ***@***.***> wrote:
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!
It would remove a ton of code from {FedData} that you would no longer have to maintain.
It would make it easier to introduce some functionality that we've talked about before, like query support (#68 <#68>) and attribute/column selection.
And, it can be done without introducing breaking changes.
Costs:
Maybe AWS is better? (I have almost no experience with AWS and am not sure this is entirely true, so take it for what it is.)
{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.
—
Reply to this email directly, view it on GitHub <#109>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7SSM2BWC4LPA7SRZEM5RLYPE773AVCNFSM6AAAAABCAQEF2GVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4DQNJXGA3TKNY>.
You are receiving this because you are subscribed to this thread.
|
|
Thanks, Kyle! I'm going to wait till they release a stable version before I start working on this (probably mid-February), then I can share a PR. Cheers. |
|
Sounds good. Thank you!
… On Jan 18, 2024, at 9:04 AM, Kenneth Blake Vernon ***@***.***> wrote:
Thanks, Kyle! I'm going to wait till they release a stable version before I start working on this (probably mid-February), then I can share a PR.
Cheers.
—
Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7SSMY7C7QSSLPWSCZXCU3YPFBZPAVCNFSM6AAAAABCAQEF2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYG43TCMBRGA>.
You are receiving this because you commented.
|
|
If you all end up taking this on, please let me know if I can be of assistance! I'm sure y'all will run into some "nice to haves" and if you do, please let me know. Additionally, if there is any progress made on this before March 10th-ish, I'd love to talk about it at Esri DevSummit |
|
Will do. Thanks @JosiahParry! |
|
Hi y'all. I've begun the implementation of this, first by simply using That being said, we can't release this update to CRAN until |
|
Yup! Totally fair point. :))) |
|
It's all good! No bugs so far, and thanks for handling those messages for zero feature results!
… On Feb 12, 2024, at 8:48 AM, Josiah Parry ***@***.***> wrote:
Yup! Totally fair point. :)))
@bocinsky <https://github.com/bocinsky> The goal is a CRAN release within the next few weeks. Before March 12! I need to sniff out as many bugs as possible and fix them before then. So...if you have any that you've encountered please do let me know. I'll keep you posted on this. Sorry for the headache!
—
Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7SSM6D4PRSXWWMULPCLMTYTI2VZAVCNFSM6AAAAABCAQEF2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZYHE2DANRXGQ>.
You are receiving this because you were mentioned.
|
|
arcgisutils 0.2.0 is released on CRAN arcgislayers is waiting for review: https://cran.r-project.org/incoming/newbies/ |
|
Hey, congratulations! 🎉 I'll switch FedData to use the CRAN version. Cheers!
… On Feb 26, 2024, at 8:23 AM, Josiah Parry ***@***.***> wrote:
arcgisutils 0.2.0 is released on CRAN
arcgislayers is waiting for review: https://cran.r-project.org/incoming/newbies/
—
Reply to this email directly, view it on GitHub <#109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7SSM3A2YXABW765QNDH2TYVSSINAVCNFSM6AAAAABCAQEF2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGQYDSOBZGI>.
You are receiving this because you were mentioned.
|
|
Great news! Installed and running checks now for FedData resubmission to CRAN |
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.
The text was updated successfully, but these errors were encountered: