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

Varun Saraf varunsaraf14 at gmail.com
Mon Mar 10 07:07:15 PDT 2014


Hi,

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?

Regards,
Varun Saraf


On Sat, Mar 8, 2014 at 12:10 AM, Varun Saraf <varunsaraf14 at gmail.com> wrote:

> 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/20140310/e324341f/attachment.html>


More information about the geos-devel mailing list