I should point out here, that the JTS relationship has been virtuous
in both directions. The GEOS community has had performance issues
which for some reason the JTS using community has not, and this has
resulted in a number of efficiency ideas which have migrated from the
GEOS list and implementations back into JTS as Martin saw the merit
in them. (Primarily rather simple short-circuit ideas which were not
required for JTS correctness but make a big difference in the Real
World when things start getting exercised.)
P
On Mar 23, 2006, at 7:39 PM, Paul Ramsey wrote:
It means that porting concepts, bug fixes, and new algorithms from
JTS to GEOS not be made difficult by differences in the code
bases. Why? Because the limiting factor in the development of
GEOS is not C++ coding expertise, it is computational geometry and
geometric algorithm expertise. We are lucky to be able to sponge
off of Martin Davis' work in JTS, and in particular his expertise
in the subject matter area. The years of experience Martin has are
not easily replicable, so even when we have clients asking us for
improvements specifically in PostGIS/GEOS (and we do), it makes
sense to have Martin do them in JTS and then port them, when they
are algorithmic and conceptual in nature.
_______________________________________________
geos-devel mailing list
[EMAIL PROTECTED]
http://geos.refractions.net/mailman/listinfo/geos-devel
