<div dir="ltr">Hi,<div><br></div><div>The second method you suggested sounds better. But as of now I am not able to judge how big/risky the implementation will be. Your views on my previous mail?</div><div><br></div><div>Regards,</div>

<div>Varun Saraf<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 8, 2014 at 12:10 AM, Varun Saraf <span dir="ltr"><<a href="mailto:varunsaraf14@gmail.com" target="_blank">varunsaraf14@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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. <br>


</div><div><br></div><div>Regards,</div><div>Varun Saraf</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 11:50 PM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Fri, Mar 07, 2014 at 11:41:26PM +0530, Varun Saraf wrote:<br>


> Hi,<br>
><br>
</div><div>> I guess it would be ideal to implement the tracking and we should give it a<br>
> shot. I think it will be worth the effort. To just document the problem and<br>
> leave it at that would be easier and we can always consider this later on<br>
> if need be. Can you tell me more about these internal geometries? Other<br>
> geometries can be tracked like you pointed out but what about these.<br>
<br>
</div>One possibility would be to _forbid_ instanciation of geometries other<br>
than via GeometryFactory, making GeometryFactory a friend of all Geometry<br>
subclasses and making all Geometry subclasses constructors private.<br>
<br>
I've no idea about the effect of such a big change on existing clients,<br>
could be a big can of worms.<br>
<br>
Another could be intercepting all outgoing Geometries resulting from<br>
C-API exposed operations so to extract the GeometryFactory pointer<br>
and thus adding them to the GeometryFactory-specific list. This one<br>
would sound much safer.<br>
<br>
But what would the advantage of such tracking be, exactly ?<br>
It would mean a user can change the "precision model" of a GEOS<br>
context w/out that invalidating/corrupting existing geometries.<br>
Basically would allow users to use the _same_ context to produce<br>
differently modeled geometries. Is that a big advantage compared<br>
to the use of different contexts ? Is it worth the risk ?<br>
<br>
Sean proposal was to use different contexts from the start.<br>
<br>
--strk;<br>
<div><div><br>
<br>
> On Fri, Mar 7, 2014 at 8:19 PM, Sandro Santilli <<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>> wrote:<br>
><br>
> > On Fri, Mar 07, 2014 at 07:57:49PM +0530, Varun Saraf wrote:<br>
> > > Hi,<br>
> > ><br>
> > > Currently, how is a GeometryFactory deleted and under what circumstances<br>
> > is<br>
> > > the finishGEOS function called? Given a GeometryFactory needs to stay<br>
> > alive<br>
> > > as long as any geometry that has been constructed with that factory. How<br>
> > > can we be sure that no geometry is still active which was created using<br>
> > > this GeometryFactory?<br>
> ><br>
> > The finishGEOS_r function is supposedly called when the user is no longer<br>
> > willing to use a specific "context". The finishGEOS function is supposedly<br>
> > called when the user is no longer willing to use the library, until next<br>
> > call to initGEOS. That's how they are documented.<br>
> ><br>
> > One way to track created geometries would be putting them in a list on<br>
> > creation and dropping them off the list when destructed (there's a C-API<br>
> > endpoint for deleting them). But some geometries are created "internally",<br>
> > as the result of operations. Those geometries would be harder to get on<br>
> > that list.<br>
> ><br>
> > Would such tracking list be worth it ? Or better to just document the<br>
> > problem and let the user be able to shoot their feet ?<br>
> ><br>
> > --strk;<br>
> > _______________________________________________<br>
> > geos-devel mailing list<br>
> > <a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
> ><br>
<br>
> _______________________________________________<br>
> geos-devel mailing list<br>
> <a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
<br>
<br>
</div></div><div>--<br>
<br>
 ()  ASCII ribbon campaign  --  Keep it simple !<br>
 /\  <a href="http://strk.keybit.net/rants/ascii_mails.txt" target="_blank">http://strk.keybit.net/rants/ascii_mails.txt</a><br>
</div><div><div>_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">http://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>