gdal
gdal copied to clipboard
georust
Borrowed vs. owned geometries
The OGR C API has two ways of accessing geometries:
- take a geometry pointer from a feature using
OGR_F_GetGeometryRef, and you're not supposed to modify or deallocate it, - clone the above geometry, or create one from scratch e.g. using
OGR_G_CreateFromWkt, and you can modify it, and you're responsible for deallocating; you can also pass ownership back to OGR by attaching it to a feature, usingOGR_F_SetGeometryDirectly.
In both cases, you have a pointer to OGRGeometryH. We should support operations on both, e.g. transforming them to JSON or WKT, and it makes sense to share the implementation.
A naive approach would be to always copy geometries, and only work with owned geometries from Rust, but that seems wasteful. But I'm probably implementing this initially, to have a working API.
Another option is to create different types for owned and borrowed geometries and share the implementation by a common trait. I've experimented with this in the feature-geometry branch.
A third option is to have an owned geometry type, which wraps a borrowed geometry type, similar to String and str.
@georust/core, any input is much appreciated :)
What would be the duplication/harm/opinions in having separate sub-packages? one for native or borrowed.
What would be the duplication/harm/opinions in having separate sub-packages? one for native or borrowed.
You mean, having completely separate types, that share nothing? It would be duplicating the implementation of a bunch of methods (exporting to json/wkt/wkb, testing for overlap/containment/intersection, computing buffer/centroid/hull/area/etc), and not allowing the API user to use them interchangeably, even though in OGR they're actually the same type.
For now we cannot avoid some package specific types. I think it's OK to keep these types and export them publicly. (Perhaps in a raw module?)
We only need to provide To/From traits and impls to convert them into our geo types for integration.
clone the above geometry, or create one from scratch e.g. using OGR_G_CreateFromWkt, and you can modify it, and you're responsible for deallocating; you can also pass ownership back to OGR by attaching it to a feature, using OGR_F_SetGeometryDirectly.
Admittedly I don't know too much about the OGR C API, but this approach sounds the most Rust-like
