[geos-devel] Exposing PrecisionModel, GeometryPrecisionReducer in the C API

[Sandro Santilli]

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
anyway.

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

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html