paleolimbot
commented
4 years ago Thanks! I'm still unsure what this particular package is trying to do..trying to learn C++ and vctrs is a big part of it. I think I also was trying to see if I could make ggplot2::coord_munch() go faster without converting from data frame with coordinates to sf to GEOS and back, get a really great labeler that required GEOS to work with grid objects, and try to simplify objects before plotting them to make it go faster.
What it's turned into is a collection of common in-memory formats and ways to convert between them. As I think about "lower level" GEOS stuff, it's hard to imagine it being useful without the ability to import and export various formats, and to have those formats work as tibble columns (which is where vctrs fits in). I think I went a bit overboard with the geo_tbl stuff, but it's the format that ggplot2, grid, and graphics devices (sort of) use, so it seemed like there should be some kind of native import/export.
I'm happy for you to make this whatever you'd like or create something new...I don't have a clear handle on the value of something even lower level than this (if or when unary, binary, and predicate operations from GEOS get implemented), but I'd be happy to help if you create something new (although my C++ is definitely being learned as I go).
A preliminary "GeomeryProvider" sketch I put here:
https://github.com/paleolimbot/geom/commit/cf66ef90c533d4bd8da3bf3b166bc0105d21c564
Basically so that operations only have to get defined once, and other packages could potentially subclass a GeometryProvider/Exporter to access GEOS functionality (without having to deal with GEOS internals). I started programming in Java where this kind of thing is common...not knowing much about C/C++, it's very possible that there is a better way.
Laziness would also be awesome! The functions in this package kind of "mark" vectors rather than convert them, which might work for what you're trying to do? I mostly write papers about metals in lakes, so I'm not great with knowing the GIS use cases.
mdsumner
CWen001
SymbolixAU
Neat work here, I've been toying with vctrs handling for geometry in related ways but you've taken this quite a long way. Just to share some thoughts, no rush on any of this just wanted to lay it out.
I'd like to have a very barebones GEOS package, one that didn't add any new types or helpers but is just low-level calls to what the library functions can do. This is similar to my vapour and PROJ package, I want access to these facilities without going through an R level of interpretation. I don't consider those user-packages, they are for developing other ideas.
The R levels and ease of useability are really important! But, they are relatively easy to add and should be in higher level package/s IMO.
It would mean pulling out the GEOS-lower level stuff here into a more "library" package, and I know that's not always straightforward, but keen to explore it if you are.
One thing I wish about sf is that it were built on a lower level foundations, one is lazy-reading (I've tried this in https://github.com/mdsumner/RGDALSQL - so no reading until collect()), the next is to keep geometries in native form (wkb, wkt, geojson) and only unpack them in R when needed. That's closer to what you have here I think. For example if GDAL is involved then use it to pass WKB into the user front-end, pass those direct to GEOS for some tasks, unpack them in R for others. (vapour can scan-read wkb, or wkt directly without the attributes - other times we work direct with WKT from other sources etc.).