[geos-devel] Exposing Precision model through C-API
Sean Gillies
sean.gillies at gmail.com
Mon Mar 17 10:16:05 PDT 2014
On Mon, Mar 17, 2014 at 2:31 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Sun, Mar 16, 2014 at 12:24:19PM -0600, Sean Gillies wrote:
> > On Mar 12, 2014 6:46 AM, "Sandro Santilli" <strk at keybit.net> wrote:
> >
> > > On Wed, Mar 12, 2014 at 06:16:00AM -0400, Paul Ramsey wrote:
> > > > 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.
> > >
> > > I also find this to be a more likely usecase.
> >
> > While agree that one model at a time (and two at the most) is the most
> > likely use case, I'm concerned about designs that limit the number. I'm
> > also reversing myself on whether there should be a precision model in the
> > global context. I'd rather GEOS did not add more global state.
> >
> > Please see the wiki page
> > http://trac.osgeo.org/geos/wiki/GSoC/CAPI_PrecisionModel for my
> (Shapely)
> > requirements.
>
> So what would you think about "parking" a pointer to the client-owned
> GeometryFactory into the "context" right before calling the geometry
> creation functions ? Such "parking" method would return the old
> GeometryFactory, so that you can pass it back. You'd only own the
> GeometryFactory objects you'd have explicitly created.
>
> I'm talking about GeometryFactory rather than PrecisionModel because
> the object referenced by geometries is really a GeometryFactory,
> not a PrecisionModel. A GeometryFactory also references a
> CoordinateSequenceFactory.
>
Sounds practical. Geometry objects will have to park their factories before
every operation, right? Offloading complexity to client code seems fair
enough.
I've updated my wiki notes to refer to geometry factories instead of models.
--
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20140317/f8b40aed/attachment-0001.html>
More information about the geos-devel
mailing list