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

[Paul Ramsey]

I would tend to expect choosing a single precision model and working
with it for a long time to be a more common usage than swapping
between lots of models. My bias.

P.

On Fri, Mar 7, 2014 at 1:40 PM, 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
>
>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel