Borrowed vs. owned geometries

[mgax]

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, using OGR_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 :)

[groteworld]

What would be the duplication/harm/opinions in having separate sub-packages? one for native or borrowed.

[mgax]

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.

[sunng87]

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.

[frewsxcv]

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

[metasim]

See also: #360