[geos-devel] RE: [jts-devel] The future of JTS and GEOS

[strk at refractions.net]

On Wed, Mar 09, 2005 at 10:53:34AM -0800, Martin Davis wrote:
> > The point I want to make, is that I think GEOS is worthwhile 
> > because of it it's relative ease of porting using a variety 
> > of compilers.  
> 
> I agree...  While GCJ is great where it fits, there's still a clear use
> for a cross-platform standalone C++ library.  

Good, then let's bring GEOS to next level.
Since GEOS API is so unstable I suggest we make a wrapper which can be
used by both C++ and C code, using objects handles, simplified memory
management and no exceptions (somthing similar to current geos_wrapper from
postgis).  The wrapper should survive big internal changes allowing
a painless transition to high performance code.

The facilities offered by the C++ language would then be used by inner
code alone, or by whoever decide to include "inner" headers giving up
stability of interface.

What do people think about this ?

--strk;

> 
> Martin Davis, Senior Technical Architect
> Vivid Solutions Inc.      www.vividsolutions.com
> Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
> Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> 
> 
> > -----Original Message-----
> > From: Frank Warmerdam [mailto:fwarmerdam at gmail.com] 
> > Sent: March 9, 2005 9:20 AM
> > To: JTS Topology Suite Development
> > Subject: Re: [jts-devel] The future of JTS and GEOS
> > 
> > 
> > On Wed, 9 Mar 2005 09:07:20 -0800, Martin Davis 
> > <mbdavis at vividsolutions.com> wrote:
> > > As Dave B points out, JTS is continuing to evolve and GEOS 
> > I suspect 
> > > is falling behind.  It's going to take some dedicated 
> > effort to keep 
> > > them both in synch.  Obviously GEOS is viable on its own at this 
> > > point; whether it continues to track JTS will really be decided by 
> > > whoever has funding and/or time to contribute.
> > 
> > Martin, 
> > 
> > As someone not contributing in any meaningful way, I hesitate 
> > to dump in my opinion, but I am personally planning to keep using 
> > GEOS rather than a .obj version of JTS, for the forseeable 
> > future. Mostly this is because I am generally afraid of the 
> > extra build and runtime complexity of the gcj solution (even 
> > more afraid when I 
> > read yesterday that the very latest point rev of gcj is required!). 
> > 
> > The point I want to make, is that I think GEOS is worthwhile 
> > because of it it's relative ease of porting using a variety 
> > of compilers.  I can live with GEOS falling behind JTS in 
> > terms of features, as long as 
> > the core operations and predicates work dependably and with at
> > least reasonable speed.   
> > 
> > How did this discussion end up being on the JTS list instead 
> > of the GEOS list? 
> > 
> > > Or perhaps we should all put our effort into encouraging 
> > the GCJ folks 
> > > to support more platforms... 8^)
> > 
> > Perhaps, but it seems unlikely we will be in a position to 
> > help them do this and no one likes folks just piping up 
> > demands stuff when they can help.  (Hey ... I resemble that remark!)
> > 
> > Best regards,
> > -- 
> > ---------------------------------------+----------------------
> ----------
> > ---------------------------------------+------
> > I set the clouds in motion - turn up   | Frank Warmerdam, 
> > warmerdam at pobox.com
> > light and sound - activate the windows | http://pobox.com/~warmerdam
> > and watch the world go round - Rush    | Geospatial 
> > Programmer for Rent
> > _______________________________________________
> > jts-devel mailing list
> > jts-devel at lists.jump-project.org 
> > http://lists.refractions.net/mailman/listinfo/jts-devel
> > 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel