Closed elipousson closed 1 week ago
Thank you!! I've provided some initial thoughts. I'm not all here mentally right now as I'm at our Esri DevSummit to talk about this. :) I'll give it a more thorough review next week.
Regarding the MULTIPOLYGON situation, I might bother the lead dev for the ArcGIS API for Python while I'm here. There may be something else that we could be doing to support it more simply. One option I have in my head is that we can take the sfc and st_cast(filter_geom, "POLYGON")
and then run the arc_select()
function for each of the polygons and rbinding them. This would make the function recursive though 😨 . Alternatively, we can error and provide a very thorough set of examples in the @details
doc that illustrate different techniques for handling it. Because if we can use multipolygons too well, finding a panacea might be a bit tough
@JosiahParry no rush on my account, I ran into both of these bugs with a project today and figured I'd just get it fixed and open the PR while I had it on my mind. Hope the conference goes well!
Curious to hear what your colleague recommends but I would strongly recommend against having the filter_geom error on MULTIPOLYGON inputs since so sf::st_read()
promotes POLYGON geometry up to MULTIPOLYGON by default when reading from a file. The original solution actually worked OK if all the geometries had some overlap. So we could add that back in as a test and use the covex hull method only if it doesn't meet that condition.
@elipousson I have time in the next few days to review this. Do you mind trying to write out what the objective of this PR is? It's a fairly large PR which makes it a bit tough to review!
It is largely still the same as in the initial description – I ran into a handful of small bugs and found more when I went to fix them. Here are the issues addressed by this PR:
collect_layer()
errored due to the responses including sf objects and empty data framesarc_select()
handles filter_geom
MULTIPOLYGON inputs in ways that did not work as I originally expected (not sure the improved way is perfect either)arc_read()
suffered a regression due to changes in arc_select()
that always returned an Object ID column (even when it wasn't included in fields)arc_read()
had an existing issue where it was not possible to select a single column named aliasThere is also some additional minor refactoring with no change in features that I addressed along the way including adding the rbind_results
, rbind_res_list
, and match_fields
helper functions.
I'm having a fair bit of trouble reviewing this PR because it's so large and broad. This PR is a bit too sweeping to merge at this moment. I think we should break this into smaller more bite-sized pieces that are a bit easier and clearer to tackle. Right now it's all a bit too entwined. I can try and piece apart what the objectives are and then we can start smaller?
Some of the things that this PR does that I think can be broken down into smaller PRs. I'll work on creating issues.
Thanks for creating all those issues! Totally understand the need to split it up. I need to get a better handle on branching so I can keep developing on my fork and throw things into branches as appropriate.
As is, these mega-PRs are just me fixing things on main as I work through an issue which can be impractical for collaboration. Did you want me to close this PR after I get the more focused ones opened? Or rename this one after pulling out anything beyond the initial scope?
Let's keep this open for now or convert to draft. I think it would be nice to crib from this for each of the PRs.
I think first of all, creating a utility row-binding function would be most immediately useful (selfishly as I'm working on arcgeocode).
What I think would be easiest / most impactful in order:
@JosiahParry I have not forgotten about this – just been busy with work. I was able to pull a new branch off from main so I can use that to implement the changes and open a new PR (one at a time unless the changes cover completely separate files) for each of those 5 items.
@elipousson no worries! I'm a bit distracted as well. I've done #1 in https://github.com/R-ArcGIS/arcgisutils/pull/42/files
Closing this one out since all of the changes are either merged or included with #186
Checklist
devtools::document()
devtools::check()
passes locallyChanges
I'll update this description with more detail later this evening.
prepare_spatial_filter()
arc_read()
created byarc_select()
now always returning OBJECTID (new issue sometime in last month?)collect_layer()
Issues that this closes
See changes. I'd add more GH issues but my existing reprex is gnarly and I don't know if/when I'll have time to pull together a good one. The
arc_read()
regression is evident in the existing errored tests – it maybe should get fixed in{arcgisutils}
if you can tell what the root source of the problem is.Follow up tasks
Update README with correct information on handling of
filter_geom
. That change could easily be added to this PR along with the updates to NEWS.