[geos-devel] Summary of design decisions for CoordinateList

[Martin Davis]

Yury and I just discussed what remains to be done to finish the design and implementation of CoordinateList within GEOS.  This is a summary of the final design, in case anyone has comments.  (Note that it repeats some of the design requirements from the original discussion a couple of weeks ago).

==========================================
CoordinateList is an interface (abstract class) that encapsulates the actual implementation of lists of Coordinates. This allows clients with their own pointlist structures to pass them into GEOS without copying them.  

A concrete implementation BasicCoordinateList is provided to handle "native" GEOS CoordinateLists (based on vectors and GEOS Coordinates).  In addition, a sample implementation PointCoordinateList based on an array of struct { 3 x double } is provided as well, as an example of how users can write adapters for their own storage format.

[** Important] When GEOS methods create CoordinateLists (e.g. in the overlay functions and buffer) it will create instances of the native BasicCoordinateList.  Users will be responsible for copying the resulting points into the their own structures, as need be.  The reason for this decision is to avoid having to associate a factory class with every Geometry.  Also, constructed CoordinateLists are likely to be copied to somewhere else anyway by the client application, so this shouldn't pose much of a problem.

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 native BasicCoordinateList *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.

==========================================

Note: I guess we *could* make the CoordinateList factory class a singleton, so that a single instance of GEOS would also use the same format for CoordinateLists.   Any thoughts on this from the team?  It's easy to add this later, anyway.

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