[geos-devel] Cross posting

Juanse georef at tie.cl
Thu Nov 14 15:03:23 EST 2002


sorry for cross posting, but no one seem to listen on the postgis list.

I am looking for Postgrass C drivers for linking Grass to Postgis and only
arrives to pdf files.

It seem that this taz.gz are non existent as independently but built in
Grass 5.1, am i right ore there is a place to search for it?

juanse
temuko-chile

----- Original Message -----
From: David Blasby <dblasby at refractions.net>
To: Geos-Devel (E-mail) <geos-devel at geos.refractions.net>
Sent: Thursday, November 14, 2002 5:00 PM
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;
>
> file://make coodinates & coordinate lists
>
> g1 = <create a geometry>
> g2 = <create a geometry>
>
>  IntersectionMatrix im(g1->relate(g2));
>
>     file://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


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.417 / Virus Database: 233 - Release Date: 09/11/02





More information about the geos-devel mailing list