[geos-devel] Status (New Example)

Martin Davis mbdavis at VividSolutions.com
Fri Apr 4 17:18:53 EST 2003

Sigh...  I guess you're right about this.  

This isn't what was intended.  I thought that the original design of the CoordinateList interface specified a method

Coordinate getAt(int i).  

This would return a Coordinate created on the stack, which should be a lot more efficient than creating a entire new Coordinate.  Possibly this message got lost somewhere along the way...  or did we try this and found it was slower or problematic?  Yury, can you remember?

The other option is to have a method getAt(int i, Coordinate& coord) which simply copies the Coordinate value into another reference object.  No new Coordinate objects are created.  Unfortunately all of the GEOS code would have to be revisited to make sure that it used this method, instead of getAt(int i).

Martin Davis, Senior Technical Architect
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: Friday, April 04, 2003 2:06 PM
> To: Yury A. Bychkov; GEOS Development List
> Subject: Re: [geos-devel] Status (New Example)
> Yury A. Bychkov wrote:
> >I've added a new example that shows how to write a 
> CoordinateList class that
> >wraps some other storage method (in this case an array of 
> point_3d) to the CVS.
> >
> >  
> >
> I've started work on the PostGIS interface to GEOS.  I'm trying to 
> decide between the normal
> CoordinateList interface (BasicCoordinateList) and a custom 
> CoordinateList:
> The "normal list" would be something like: (cf. 
> CoordinateListsExample.cpp in examples/)
> CoordinateList 
> *cl1=CoordinateListFactory::internalFactory->createCoordinateList();
> cl1->add(*(new Coordinate(140,120)));
> So, I'd convert my PostGIS point lists into a CoordinateList.  This 
> would require
> 1. about 2* the memory since I'll have my PostGIS POINT3D and GEOS 
> Coordinates around.
> 2. the time required to make the coordinates
> The CustomCoordinate (cf. CustomPointCoordinateList.cpp in examples/) 
> would allow me
> to wrap my PostGIS POINT3D arrays into a CoordinateList.
> On first account, this looks more memory efficient and time 
> efficient, 
> but upon closer
> examination, it looks worse.  Lets look at the getAt(int) function:
> Coordinate& CustomPointCoordinateList::getAt(int pos){
>     point_3d pt;
>     if (pos>=0 && pos<size) {
>         pt=pts[pos];
>         return *(new Coordinate(pt.x,pt.y,pt.z));
>     } else
>         throw "CustomPointCoordinateList exception: can't retrieve 
> element\n";
> }
>  From a time perspective, any GEOS function  (like relate() ) 
> that looks 
> at each of the points in a
> geometry will have to create a new Coordinate() for each 
> PostGIS POINT3D.  
> Its even worse if you look at each of the points
> in a geometry twice (or more) - you'll construct several Coordanates. 
>  This makes the
> getAt() function *very* costly.  It also means that coordlist.get(3) 
> will return a different object every
> invocation.
> For memory usage,  the GEOS function do something like build an index 
> (ie. all the Coordinates are stored somewhere),
> we are not saving any memory, not to mention we could be 
> leaking memory 
> with multiple calls to getAt().
> So, it appears that the correct interface to use would be the 
> BasicCoordinateList, not a custom one.  
> Comments?
> dave
> ps. The PostGIS POINT3D is identical to the GEOS geom.h point_3d.
> _______________________________________________
> 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