[geos-devel] Question about Geometry andGeometryFactoryrelationship...

Fri May 13 14:10:07 EDT 2005

>Binary operations can be a problem, as you have 
> two geoms with possibly two different factories. 

The JTS convention is to use the geometry of the left hand operand (the
instance the overlay method is run on).

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 
> strk at refractions.net
> Sent: May 13, 2005 12:29 AM
> To: GEOS Development List
> Subject: Re: [geos-devel] Question about Geometry 
> andGeometryFactoryrelationship...
> 
> 
> 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
> 