[geos-devel] Question about Geometry and GeometryFactoryrelationship...

Fri May 13 10:13:28 EDT 2005

On Fri, May 13, 2005 at 08:32:16AM -0500, Steve Lime wrote:
> Sorry, I was refering to deleting a Geometry and GeometryFactory at the
> same time which would cause problems with other Geometry objects created
> from one another via buffers, convex hulls or whatever. I have been
> hanging a Geometry off of a MapServer C shape structure and would have
> to include a GeometryFactory as well to avoid threading issues. Each
> shape would then have its own GeometryFactory which would be deleted
> when a shape is deleted.

No, you can't safely destroy the GeometryFactory element of a
Geometry. Can you tell me more about the issues of keeping
a single instance of the GeometryFactory ? It is a read-only
structure (all state defined at construction time).

--strk;

> 
> I wish C/C++ was multi-threaded by default with a memory manager but
> they're not...
> 
> Steve
> 
> >>> strk at refractions.net 05/13/05 2:28 AM >>>
> On Fri, May 13, 2005 at 12:11:57AM -0500, Stephen Lime wrote:
> > One other question then. Most of the time you need a GeometryFactory 
> > when creating a Geometery, but not always. What happens in the case of
> 
> > constructing a buffer?
> > 
> > e.g.
> > 
> >   Geometry *bg = g->buffer(width);
> > 
> > At what GeometryFactory does bg point? The same as g I assume. This 
> > makes my workaround of keeping a GeometryFactory and Geometry coupled 
> > together within a MapServer shape kinda difficult, unless there's an 
> > easy way to point a Geometry at another factory of its own. Otherwise 
> > if features are deleted in the wrong order they may well take other 
> > features with them.
> 
> Buffer operation will use factory of input. 
> Geometry destruction won't destruct the GeometryFactory it points to.
> Binary operations can be a problem, as you have two geoms with possibly
> two different factories. I have to say I don't know what should
> be expected then. Martin should be able to answer, and I can check 
> that GEOS respect the expected behaviour.
> 
> --strk;
> 
> 
> > 
> > Steve
> > 
> > On May 11, 2005, at 5:20 PM, strk at refractions.net wrote:
> > 
> > >On Wed, May 11, 2005 at 12:21:05PM -0500, Steve Lime wrote:
> > >>Hi Martin: Thanks for the clarification, something to think about
> > >>anyway. In lieu of a code change at the moment I'll couple the two
> > >>myself. GEOS Geometry's are buried behind MapServer shapes so the
> > >>developer/user doesn't see 'em. With MapServer there no logical
> > >>candidate structure/object to attach the factory to without
> explicitly
> > >>creating something new and GEOS specfic. I'd rather not go there.
> > >>
> > >>Is the factory object relatively lightweight so that constantly
> > >>instatiating new objects doesn't hurt performance?
> > >
> > >This must be profiled to tell.
> > >
> > >The default constructor for a GeometryFactory:
> > >
> > >GeometryFactory::GeometryFactory() {
> > >        precisionModel=new PrecisionModel();
> > >        SRID=0;
> > >        
> > >coordinateListFactory=DefaultCoordinateSequenceFactory::instance();
> > >}
> > >
> > >The default constructor for a PrecisionModel:
> > >
> > >PrecisionModel::PrecisionModel(){
> > >        modelType=FLOATING;
> > >        scale=1.0;
> > >}
> > >
> > >So it takes 2 ints, 1 double and 2 pointers of size + 3 function
> > >calls (own and PM ctors and ::instance).
> > >
> > >Would it be ok for threading if GEOS provides a
> > >defaultGeometryFactory ?
> > >
> > >--strk;
> > >
> > >>
> > >>Steve
> > >>
> > >>>>>mbdavis at VividSolutions.com 5/11/2005 12:02:18 PM >>>
> > >>Geometrys need some metadata to allow methods to execute.  This
> > >>currently includes things like PrecisionModel and SRID (and may grow
> > >>to
> > >>include more things in the future).  Rather than duplicate these for
> > >>every geometry, the GF is referenced by the geometry and shared with
> > >>any
> > >>created geometrys.  This works well in the Java world.
> > >>
> > >>In the C++ world if this is a problem I guess each Geometry could
> own
> > >>its own copy of the GF.  This would require a code change to make
> > >>Geometrys copy the GF for created Geometrys, rather than keep a
> > >>reference to it.
> > >>
> > >>Martin Davis, Senior Technical Architect
> > >>Vivid Solutions Inc.      www.vividsolutions.com
> > >>Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
> > >>Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: geos-devel-bounces at geos.refractions.net
> > >>>[mailto:geos-devel-bounces at geos.refractions.net] On Behalf Of
> > >>>Steve Lime
> > >>>Sent: May 11, 2005 9:52 AM
> > >>>To: geos-devel at geos.refractions.net
> > >>>Subject: [geos-devel] Question about Geometry and
> > >>>GeometryFactoryrelationship...
> > >>>
> > >>>
> > >>>Hi All: I'm running into trouble making a clean integration
> > >>>of GEOS into MapServer. Problem is that GeometryFactory
> > >>>objects must persist while any Geometry objects spawned from
> > >>>that factory are in us. This makes it necessary to either use
> > >>>a global factory which is problematic with theading, or
> > >>>somehow couple the two so that they are created, persist and
> > >>>are deleted together. I'm curious why Geometry's cannot
> > >>>stand-alone? Perhaps I'm missing something obvious in my
> > >>>implementation.
> > >>>
> > >>>Steve
> > >>>
> > >>>Stephen Lime
> > >>>Data & Applications Manager
> > >>>
> > >>>Minnesota DNR
> > >>>500 Lafayette Road
> > >>>St. Paul, MN 55155
> > >>>651-297-2937
> > >>>_______________________________________________
> > >>>geos-devel mailing list
> > >>>geos-devel at geos.refractions.net
> > >>>http://geos.refractions.net/mailman/listinfo/geos-devel
> > >>>
> > >>_______________________________________________
> > >>geos-devel mailing list
> > >>geos-devel at geos.refractions.net
> > >>http://geos.refractions.net/mailman/listinfo/geos-devel
> > >>_______________________________________________
> > >>geos-devel mailing list
> > >>geos-devel at geos.refractions.net
> > >>http://geos.refractions.net/mailman/listinfo/geos-devel
> > >_______________________________________________
> > >geos-devel mailing list
> > >geos-devel at geos.refractions.net
> > >http://geos.refractions.net/mailman/listinfo/geos-devel
> > >
> > 
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel