Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any chance of updating the package to work natively with sf? #3

Closed
dwachsmuth opened this issue Feb 22, 2020 · 1 comment
Closed

Any chance of updating the package to work natively with sf? #3

dwachsmuth opened this issue Feb 22, 2020 · 1 comment

Comments

@dwachsmuth
Copy link

I know I can just use as(x, "Spatial") on my sf polygons before I send them through polyCub, but it would be great if I could cut out that step. Seems like the R spatial community has moved pretty decisively to sf now, so is there any chance this conversion could be incorporated into the polyCub package?

@bastistician
Copy link
Owner

Sounds like a reasonable extension. I don't have much experience with sf, but to me it seems that polyCub.SV() and polyCub.iso() should already work for a "POLYGON" object, since this is a simple list of coordinate matrices (which the internal default xylist method understands). Did you try using polyCub with a "POLYGON" object without prior transformation to "Spatial"?

Supporting the "MULTIPOLYGON" class would require special treatment (but easy to implement). Would it be useful if polyCub.SV and polyCub.iso understood "MULTIPOLYGON" objects from sf?

BTW, polyCub.midpoint() should already work with (MULTI)POLYGON because sf (>= 0.8-1) registers suitable as.owin conversion methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants