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; _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
