[geos-devel] Coordinate & Coordinate list

[Martin Davis]

I've looked at the implementation of CoordinateList.  It seems to provide the semantics that I had in mind for CoordinateLists (with one exception, discussed below).  These semantics were based on the following design requirements:

CoordinateList should provide an abstract wrapper to hide the actual implementation of lists of Coordinates, and to take care of memory management. This allows clients with their own pointlist structures to pass them into JTS without copying them.  A default implementation will be provided to support clients with no structure of their own, and also for internal use in GEOS.  

CoordinateLists are immutable - in the few cases in GEOS where it is required to change the value of one or many coordinates in a Geometry, a new CoordinateList will be created and the old one deleted.  

It is up to the implementation of CoordinateList subclasses how they handle the delete operator.  A CoordinateList that wrappers a client pointlist will probably not delete that memory when the wrapper object is deleted.  The GEOS-provided concrete CoordinateList *will* delete its list of points.  

For efficiency, CoordinateList point storage should be implemented as an array of Coordinate values (NOT a list of pointers to coordinates).

GEOS Geometry objects "own" their CoordinateLists.  All CoordinateLists are deleted when the Geometry itself is deleted.  CoordinateLists are not shared - when new Geometrys are constructed (e.g in the overlay methods) new CoordinateLists will be constructed internally for the new Geometry.

The thing GEOS is currently missing is defining CoordinateList as an interface class (ie. class containing only pure virtual functions).  The current CoordinateList implementation would be provided as a default (called say ArrayCoordinateList). As an example, we should also provide a implementation which wrappers an array of POINT structs, and does not delete them.

Dave, I think this takes care of the issues you've raised below.  There's no need for a DieDieDie() function, since the regular Geometry delete operators will completely take care of deleting all storage associated with the Geometry.

Martin Davis, Senior Technical Specialist
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com


> -----Original Message-----
> From: David Blasby [mailto:dblasby at refractions.net]
> Sent: Thursday, November 14, 2002 12:00 PM
> To: Geos-Devel (E-mail)
> Subject: [geos-devel] Coordinate & Coordinate list
> 
> 
> I took a quick look at the CoordinateList class.
> 
> This seems like a fairly foundational class, and I think efficiency
> improvements here would trickle up the system quite well.
> Unfortunately,  changes could cause lots of changes to other 
> portions of
> code.
> 
> Java always passes things by reference, so in most cases it 
> ought to be
> okay to just move around pointers to objects instead of the object.
> But, you'll have to be carefull about memory management & unexpected
> changes to objects, and when to actually delete stuff.
> 
> In many cases, the objects are not allocated, de-allocated, or copied
> often so it wouldnt be worth the effort to change them.
> 
> The obvious way to speed things up is to *never* copy 
> coordinates if you
> dont have to.  That means making the CoordinateList keep a list of
> pointers to Coordinate, have set() take a pointer to a coordinate, and
> get() return a pointer to coordinate.
> 
> How are things handled in objects like Linestring, linear ring, and
> polygon.  Are they just carrying around a Coordinate list?  If so, it
> should probably just be carrying around a pointer to a 
> coordinate list.
> That way copying, say, a linear ring would be very quick (just hard to
> know when to actually delete the coordinate list).
> 
> Hopefully this will give us lots of speed ups and memory efficienty by
> only changing a few things...
> 
> 
> But I dont know what's actually using these things, so I could be
> wrong.  What do you folks think?
> 
> dave
> ps. a Geometry.DieDieDie() function might be needed to ensure that
> memory is actually released.
> 
> 
> {
> Geometry *g1,*g2;
> 
> //make coodinates & coordinate lists
> 
> g1 = <create a geometry>
> g2 = <create a geometry>
> 
>  IntersectionMatrix im(g1->relate(g2));
> 
>     //im will be released automagically when block ends
> 
> g1.DieDieDie();  // ensure that everything is actually released
> g2.DieDieDie(); // including all the CoordinateList and Coordinates
> }
> 
> We'll have to be careful that there are no "shared" 
> Coordinates - ie. if
> you union g1 and g2, the result should have all new 
> coordinates instead
> of re-using the old ones (because someone could de-allocate them when
> you're not looking).
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>