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

Steve Lime steve.lime at dnr.state.mn.us
Fri May 13 11:55:15 EDT 2005

That's certainly easiest, I'll admit I spent a lot of time studying your
postGIS implementation as I did the MapServer stuff and that was your
approach. There are startup and cleanup issues though so you make sure
only one thread can instantiate the factory and that it goes away at
some point (although the amount of memory leaked is pretty small). I've
dropped a note to a few of the threading experts on the MapServer side
for their opinions. I don't think any GEOS changes are warranted...


>>> chodgson at refractions.net 5/13/2005 9:33:40 AM >>>
Well, if GeometryFactory had any internal state at all, then there
be the risk of two different threads trying to simultaneously access 
and/or modify it. However, since as you say it is read only, then it
be perfectly thread-safe to keep just one of them around and use the 
same one in all threads for all geometries. That would certainly be the

easiest to code, wouldn't it Steve?


strk at refractions.net wrote:
> On Fri, May 13, 2005 at 08:32:16AM -0500, Steve Lime wrote:
>>Sorry, I was refering to deleting a Geometry and GeometryFactory at
>>same time which would cause problems with other Geometry objects
>>from one another via buffers, convex hulls or whatever. I have been
>>hanging a Geometry off of a MapServer C shape structure and would
>>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...
>>>>>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
>>>constructing a buffer?
>>>  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
>>>together within a MapServer shape kinda difficult, unless there's an

>>>easy way to point a Geometry at another factory of its own.
>>>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
>>Binary operations can be a problem, as you have two geoms with
>>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.
>>>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
>>>>>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
>>>>>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;
>>>>The default constructor for a 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 ?
>>>>>>>>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
>>>>>include more things in the future).  Rather than duplicate these
>>>>>every geometry, the GF is referenced by the geometry and shared
>>>>>created geometrys.  This works well in the Java world.
>>>>>In the C++ world if this is a problem I guess each Geometry could
>>>>>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
>>>>>>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
>>>>>>Stephen Lime
>>>>>>Data & Applications Manager
>>>>>>Minnesota DNR
>>>>>>500 Lafayette Road
>>>>>>St. Paul, MN 55155
>>>>>>geos-devel mailing list
>>>>>>geos-devel at geos.refractions.net 
>>>>>geos-devel mailing list
>>>>>geos-devel at geos.refractions.net 
>>>>>geos-devel mailing list
>>>>>geos-devel at geos.refractions.net 
>>>>geos-devel mailing list
>>>>geos-devel at geos.refractions.net 
>>>geos-devel mailing list
>>>geos-devel at geos.refractions.net 
>>geos-devel mailing list
>>geos-devel at geos.refractions.net 
> _______________________________________________
> 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 

More information about the geos-devel mailing list