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

[R]: Export wk reader & writer S3 methods? #69

Open
anthonynorth opened this issue Oct 23, 2023 · 4 comments
Open

[R]: Export wk reader & writer S3 methods? #69

anthonynorth opened this issue Oct 23, 2023 · 4 comments

Comments

@anthonynorth
Copy link
Contributor

Could we export wk_handle.geoarrow_array and wk_writer.geoarrow_array S3 methods? This will allow for integration with {wk} readers, writers and filters.

Geoarrow arrays don't currently have their own class. I'm assuming this is planned?

I think this is all we need (once the geoarrow_array class exists)

wk_handle.geoarrow_array <- function(handleable, handler, size = NA_integer_, ...) {
  handler <- wk::as_wk_handler(handler)
  geoarrow::geoarrow_handle(handleable, handler, size)
}

wk_writer.geoarrow_array <- function(handleable, schema = NULL) {
  # what is an apppropriate default?
  if (is.null(schema)) {
    schema <- geoarrow::infer_geoarrow_schema(handleable)
  }
  geoarrow::geoarrow_writer(schema)
}

wk::wk_count(my_geoarrow_array)
@paleolimbot
Copy link
Contributor

Good spot! I haven't had time to circle back to this recently...the main blocker was the geoarrow_array class, as you noted. I'd been planning to call it geoarrow_vctr and have it be basically the same as the geoarrow_vctr here: https://github.com/paleolimbot/geoarrow/blob/master/R/vctr.R .

@anthonynorth
Copy link
Contributor Author

Is the intent to bring across the geoarrow_vctr as-is + necessary fixes?

Does this package completely replace paleolimbot/geoarrow?

@paleolimbot
Copy link
Contributor

Does this package completely replace paleolimbot/geoarrow?

Yes! I also need to port over read_geoparquet() and read_geoparquet_sf() as well as the Arrow C++ extension type stuff. The code in paleolimbot/geoarrow was based on an early attempt at what is now nanoarrow and geoarrow-c, which have much better support.

Is the intent to bring across the geoarrow_vctr as-is + necessary fixes?

Yes, although I was planning to have it be as minimal as possible and perhaps more aggressively materialize (maybe via arrow for now) when doing anything other than slicing. The minimal useful implementation doesn't really need subsetting at all...just something to exist that somebody can call sf::st_as_sfc() (or geos::as_geos_geometry(), etc.).

@anthonynorth
Copy link
Contributor Author

Ok. I'll follow up on the geoarrow_vctr discussion with a separate issue.

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