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

Chris Hodgson chodgson at refractions.net
Fri May 13 10:33:40 EDT 2005 

Well, if GeometryFactory had any internal state at all, then there would 
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 may 
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?

Chris

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 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
> 
> _______________________________________________
> 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