[Qgis-developer] new dependency on GEOS C++ library

[Sandro Santilli]

On Thu, Oct 01, 2015 at 02:01:53PM +0200, Sandro Mani wrote:
> On 01.10.2015 13:55, Sandro Santilli wrote:

> >  GEOSGeometry* GEOSGeometry_setFactory( GEOSGeometryFactory* factory, int roundCoordinates );
>
> >But note that for such a call, the "factory" parameter would need
> >to be alive for the whole lifetime of the returned GEOSGeometry
> >_and_ for any further product from it (operation involving it as an input).
> >
> >These GeometryFactory links are sticky, that's what makes it hard to
> >deal with them.
> 
> If one sets the reduced precision factories on the geometries, does
> one still need to explicitly reduce those geometries prior to
> performing the analysis operation, or are they reduced implicitly
> while performing the operation?

Operation never pre-reduce inputs.
That's why I added the second parameter.
The only reason to pass "false" would be an optimization in case you
know in advance your geometry is already constrained to the grid
registered in the factory (that'd be case 1 in my mail from
https://lists.osgeo.org/pipermail/geos-devel/2015-January/007097.html)

The only way to construct geometries with the GEOS C-API
right now is via WKB or WKT or passing a CoordinateSequence to any
GEOSGeom_create* function. None of them applies any rounding and
attached a singleton-like GeometryFactory to the result. So right
now all geometries out of the C-API contain a reference to the very
same GeometryFactory.

Exposing function like:

 GEOSIntersection_reducedPrecision

Would pose the question of whether or not the coordinates of input
should be reduced. If we do reduce them, then chained operations
would keep rounding the same coordinates again and again, while
by storing the precision info inside each Geometry we are defining
what is already rounded and to which grid.

As known from the beginning, the challenge here is dealing with
management of the many GeometryFactory objects that would result
from the possibility of expressing them freely, and I start thinking
there's no way out of this than adding refcounting to the
GeometryFactory object so that it self-manages.

I'll be trying something to that extent for the time being.

As for QGIS, I guess you could have a function to "reduce" and a
function to "register" a factory. So chained operations would:

 0. reduce
 1. register reduced factory
 2. perform operation 1
 3. perform operation 2
 4. ...
 5. register original factory

In this case the "reduced factory" would just have a short living, and
at the end of the operation chain there would still be a single
factory alive.

--strk;