Draft of a geometry operations applicator #1112
Conversation
|
|
||
| from libcpp.unordered_map cimport unordered_map | ||
|
|
||
| cdef OGRGeometryH segmentize(OGRGeometryH geom, double max_length): |
There was a problem hiding this comment.
Because OGR_G_Segmentize is an oddball and returns nothing (void).
| func_map[1] = <geometry_func>segmentize | ||
|
|
||
| cdef geometry_func func_alias(int choice): | ||
| return func_map[choice] |
There was a problem hiding this comment.
We can't just put OGR_G_Segmentize (for example) in a Python dict. https://stackoverflow.com/a/56708967 was very helpful in showing a solution.
|
|
||
| op_map = { | ||
| "segmentize": 1 | ||
| } |
There was a problem hiding this comment.
The map to the map of OGR functions.
| for geom in geoms: | ||
| ogr_geom1 = _geometry.OGRGeomBuilder().build(geom) | ||
|
|
||
| for op_name, op_arg in operations: |
There was a problem hiding this comment.
Basically it's a per-geometry pipeline implemented in C.
The other obvious design is to add segmentize &c as methods to our Geometry class. But performance won't be great until version 2.0 of fiona when Geometry is an extension class and carries an OGRGeometryH or a zero-copy data structure around with it.
There was a problem hiding this comment.
Might not be bad to wait until 2.0 for this as the Geometry class seems to have the potential to significantly impact on the design.
Resolves #982