[geos-devel] Exposing PrecisionModel, GeometryPrecisionReducer in the C API
strk at keybit.net
Thu Oct 1 09:47:00 PDT 2015
Cleaned up proposal. No copying, using 0 for FLOATING and returning
* Set the geometry's precision, optionally rounding all its
* coordinates to the precision grid (if it changes).
* @param gridSize size of the precision grid, or 0 for FLOATING
* @param forceSnap specifies whether snapping to the precision grid
* should be forced: -1 prevents snapping, which can
* be used when the input is known to be already
* rounded to the target grid; 0 only snaps if the
* new precision grid is not equal or compatible with
* the new precision grid; 1 always snaps.
* @retuns -1 on exception, previous size of precision grid otherwise.
extern int GEOS_DLL *GEOSGeom_setPrecision_r(
double gridSize, int forceSnap);
I guess one might want a _getPrecision too...
On Thu, Oct 01, 2015 at 06:42:32PM +0200, Sandro Santilli wrote:
> On Thu, Oct 01, 2015 at 06:14:10PM +0200, Sandro Mani wrote:
> > On 01.10.2015 18:08, Sandro Santilli wrote:
> > >On Thu, Oct 01, 2015 at 06:02:20PM +0200, Sandro Santilli wrote:
> > >>Sandro, others:
> > >>here's what I'm thinking to add as the single new signature
> > >>to the C-API for GEOS-3.6.0, what do you think ?
> > >>
> > >> /*
> > >> * Set the geometry's precision, optionally rounding all its
> > >> * coordinates to the precision grid (if it changes).
> > >> *
> > >> * @param gridSize size of the precision grid, or -1 for FLOATING
> > >> * precision.
> > >> * @param forceSnap specifies whether snapping to the precision grid
> > >> * should be forced: -1 prevents snapping, which can
> > >> * be used when the input is known to be already
> > >> * rounded to the target grid; 0 only snaps if the
> > >> * new precision grid is not equal or compatible with
> > >> * the new precision grid; 1 always snaps.
> > >> *
> > >> */
> > >> extern GEOSGeometry GEOS_DLL *GEOSGeom_setPrecision_r(
> > >> GEOSContextHandle_t handle,
> > >> double gridSize, int forceSnap);
> > >>
> > >>Of course it can only work if the memory management for
> > >>GeometryFactory is automatic, as proposed in the PR
> > >>(which might be dangerous for any existing C++ client out there).
> > >Of course there must be a GEOSGeometry argument too:
> > >
> > > GEOSGeometry *GEOSGeom_setPrecision_r(
> > > GEOSContextHandle_t handle,
> > > const GEOSGeometry *g,
> > > double gridSize, int forceSnap);
> > >
> > >I'm not sure about returning a copy. One idea was, in the long run,
> > >to also make GEOSGeometry objects automatically managed as per memory
> > >lifetime, such thing would be easier by threating geometries as
> > >immutable objects (and this is also the policy used in JTS); but
> > >there's a known single function that is already not respecting that
> > >immutability, which is GEOSNormalize.
> > As far as QGIS is concerned, it might also be an idea to just have a
> > function which sets the precision geos-context-wide:
> > void GEOS_setPrecision_r(GEOSContextHandle_t handle, double gridSize)
> > removing the need to do all the cloning of geometries just to reduce
> > the precision. After all, all QGIS geometry processing functions
> > would benefit from reduced precision computations.
> Note that the _rounding_ of coordinates is expected to be performed
> outside of the processing functions, for them work correctly, so
> you'll need to perform this rounding/scaling step at some point
> A generic GEOS_setPrecision sounds interesting, but then you'll need
> to go through each and every function returning a GEOSGeometry and
> specify what happens to it depending on the precision.
> For example:
> - should GEOSGeom_clone assign the "context" precision
> to the clone; should it scale/round ?
> - should GEOSProject use the input or the context precision
> for the output ?
> - should GEOSIntersection use the context precision or one
> of the input precision ?
> - should GEOSGeom_createLineString round the input
> coordinates to the context precision ?
> On the C++ side, it is the input that determines the output precision
> (smallest precision in case of multiple inputs) and rounding of input
> only happens with the WKTReader.
> Note that a function capable of rounding would still be needed.
> Surely allowing for in-place editing would help cases in which
> you just want to round w/out changing the reference precision:
> GEOSGeom_setPrecision_r(g, 2, 0); // snap to grid of size 2
> GEOSGeom_setPrecision_r(g, -1, -1); // set precision to floating
> () Free GIS & Flash consultant/developer
> /\ http://strk.keybit.net/services.html
More information about the geos-devel