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

Steve Lime steve.lime at dnr.state.mn.us
Fri May 13 09:32:16 EDT 2005


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.

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




More information about the geos-devel mailing list