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

[Varun Saraf]

Hi,

I think the reason to use different contexts is primarily to use different
precision models. If it is then its unnecessary to delete a context and
create a new one just to change the precision model. I might be wrong here.

Regards,
Varun Saraf


On Fri, Mar 7, 2014 at 11:50 PM, Sandro Santilli <strk at keybit.net> wrote:

> 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20140308/ab907070/attachment-0001.html>