[geos-devel] Status (New Example)
Yury A. Bychkov
me at yury.ca
Sat Apr 5 05:32:22 EST 2003
1. Original design was to return the Coordinate on stack (getAt(int i) had
return Coordinate(pt.x,pt.y,pt.z) instead of return *(new
Coordinate(pt.x,pt.y,pt.z)) ), but, if I remember correctly, that caused a
problem in a GNU compile.
2. Even if we'll solve the memory issue (maybe there are some options that could
be specified to fix the GNU compile), as far as I can see, the time issue in
unfixable, because if we store the data in another format (point_3d) and the
caller needs a Coordinate, then it HAS to be converted into a Coordinate every
time the call is made. Hopefully someone has an idea how to avoid that.
Yury
----- Original Message -----
From: "Martin Davis" <mbdavis at VividSolutions.com>
To: "GEOS Development List" <geos-devel at geos.refractions.net>; "Yury A. Bychkov"
<reply at yury.ca>; "Dave Blasby (E-mail)" <dblasby at refractions.net>
Sent: Friday, April 04, 2003 2:18 PM
Subject: RE: [geos-devel] Status (New Example)
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
>
_______________________________________________
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