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

[Stephen Lime]

I'm sure there are others lurking that are far more qualified to 
comment on threading. How would a default factory be implemented? if it 
took care of the dependancy I first asked about then I think it would 
simplify life for what I'm working on.

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
>