[geos-devel] Exposing Precision model through C-API

[Sandro Santilli]

On Fri, Mar 07, 2014 at 11:41:26PM +0530, Varun Saraf wrote:
> Hi,
> 
> I guess it would be ideal to implement the tracking and we should give it a
> shot. I think it will be worth the effort. To just document the problem and
> leave it at that would be easier and we can always consider this later on
> if need be. Can you tell me more about these internal geometries? Other
> geometries can be tracked like you pointed out but what about these.

One possibility would be to _forbid_ instanciation of geometries other
than via GeometryFactory, making GeometryFactory a friend of all Geometry
subclasses and making all Geometry subclasses constructors private.

I've no idea about the effect of such a big change on existing clients,
could be a big can of worms.

Another could be intercepting all outgoing Geometries resulting from
C-API exposed operations so to extract the GeometryFactory pointer
and thus adding them to the GeometryFactory-specific list. This one
would sound much safer.

But what would the advantage of such tracking be, exactly ?
It would mean a user can change the "precision model" of a GEOS
context w/out that invalidating/corrupting existing geometries.
Basically would allow users to use the _same_ context to produce
differently modeled geometries. Is that a big advantage compared
to the use of different contexts ? Is it worth the risk ?

Sean proposal was to use different contexts from the start.

--strk;


> On Fri, Mar 7, 2014 at 8:19 PM, Sandro Santilli <strk at keybit.net> wrote:
> 
> > On Fri, Mar 07, 2014 at 07:57:49PM +0530, Varun Saraf wrote:
> > > Hi,
> > >
> > > Currently, how is a GeometryFactory deleted and under what circumstances
> > is
> > > the finishGEOS function called? Given a GeometryFactory needs to stay
> > alive
> > > as long as any geometry that has been constructed with that factory. How
> > > can we be sure that no geometry is still active which was created using
> > > this GeometryFactory?
> >
> > The finishGEOS_r function is supposedly called when the user is no longer
> > willing to use a specific "context". The finishGEOS function is supposedly
> > called when the user is no longer willing to use the library, until next
> > call to initGEOS. That's how they are documented.
> >
> > One way to track created geometries would be putting them in a list on
> > creation and dropping them off the list when destructed (there's a C-API
> > endpoint for deleting them). But some geometries are created "internally",
> > as the result of operations. Those geometries would be harder to get on
> > that list.
> >
> > Would such tracking list be worth it ? Or better to just document the
> > problem and let the user be able to shoot their feet ?
> >
> > --strk;
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/geos-devel
> >

> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel


-- 

 ()  ASCII ribbon campaign  --  Keep it simple !
 /\  http://strk.keybit.net/rants/ascii_mails.txt