[geos-devel] Issue with returning Coordinate * rather than value

Martin Davis mbdavis at VividSolutions.com
Fri Nov 15 12:46:57 EST 2002


Yep, JTS objects cache data internally about the values of their Coordinates.  (The best example is the bounding box).  If Coordinates change without the knowledge of the object, this makes the cached data inconsistent.  There's a possibility of adding more cached data as well - a primary example would be to cache the fact that a geometry is valid.

We currently do provide a geometryChanged() method in JTS 1.2 to allow users to manually flush the cached data.  This is fine for the "user beware" approach, but it would be nice to have an API that allowed us to do better.

(See my following note about how we can get this as a bonus side effect of dealing with another problem).

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: Friday, November 15, 2002 9:21 AM
> To: geos-devel at geos.refractions.net
> Subject: Re: [geos-devel] Issue with returning Coordinate * 
> rather than
> value
> 
> 
> Martin Davis wrote:
> 
> > Yep, that's what I meant.  Ok, I guess I can live with that...
> >
> > On a philosophical note, I always prefer solutions that 
> help save programmers from shooting themselves in the foot... 
> seems to me that most of the history of the development of 
> programming languages is concerned with doing exactly that, 
> and it's nice to learn from that trend.  But timelines are 
> short - next release, I guess.  The nasty thing is that once 
> this horse is out of the door, it's disappeared around the 
> bend never to be seen again...
> 
> I agree with you here martin, but I am really wanting to get 
> performance up.
> 
> When would modifying internal structures be a problem?
> 
> {
>     Geometry *g1;
>     Geometry *g2;
>     Geometry *g3;
> 
>     g1  = ....;
>     g2  = ...;
> 
> 
>     g3 = g1->intersect(g2);
> 
>     // mess around with some of g1's coordinates BAD ME
> 
>         CoordinateList coords = 
> g1->getPoints().toCoordinateList(); //or whatever it is
>         coords.getAt(1)->x = 25;  // EVIL LAUGH
> 
>     delete g3;
> 
>     g3 = g1->intersect(g2);
>    double len = g1->length();
> }
> 
> This shouldnt give any funny results unless you're storing 
> meta-information (like an index or graph) inside the 
> geometries that would require re-calculating if the internal 
> coordinate change.
> 
> We could have an alternate structure to CoordinateList that 
> has an interface more like:
> 
>     Coordinate *getAt(int i);  // fast but a little dangerous
>     Coordinate getAtSafe(int i); // or some such thing for 
> evil programmers.
> 
> dave
> 
> 
> _______________________________________________
> 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