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

[Sandro Santilli]

Cleaned up proposal. No copying, using 0 for FLOATING and returning
previous precision.

  /**
   * 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
   *                 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.
   * @retuns -1 on exception, previous size of precision grid otherwise.
   *
   */
  extern int GEOS_DLL *GEOSGeom_setPrecision_r(
                                         GEOSContextHandle_t handle,
                                         GEOSGeometry *g,
                                         double gridSize, int forceSnap);

I guess one might want a _getPrecision too...

--strk;


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