[geos-devel] Current Status

[strk]

On Mon, Apr 26, 2004 at 09:11:04AM -0700, Martin Davis wrote:
> > I've checked out JTS-1.4 and the change is there too, 
> > although not documented in the release notes and mismatching with the 
> > comment that preceedes its definition. I suppose it's a bug
> > in JTS ported to GEOS. Martin ?
> 
> > Let's wait for Martin response. It seems that the new 
> > interface lacks the ability of specifying the resulting 
> > geometry precision model, that will get the internal 
> > precision model... and this seems to me a bug.
> 
> This isn't a bug in JTS.  The signature of the
> GeometryFactory#toGeometry method is intentional.   The precision model
> and other metadata is already known by the GeometryFactory, so there's
> no need to pass it to the toGeometry method.  Really, the toGeometry
> method is only there to support converting Envelopes to a Geometry -
> it's not intended for outside use.  Probably should be package-private
> in JTS.
> 
> Make sense?

Sure, so the bug is in the comment alone :)
If that function is not part of the API, what code was trying to use
it Carl ?

--strk;

> 
> 
> Martin Davis, Senior Technical Architect
> Vivid Solutions Inc.
> Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
> Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> 
> 
> > -----Original Message-----
> > From: strk [mailto:strk at keybit.net] 
> > Sent: April 25, 2004 2:33 AM
> > To: Carl Anderson; Martin Davis
> > Cc: geos-devel at geos.refractions.net
> > Subject: Re: [geos-devel] Current Status
> > 
> > 
> > On Fri, Apr 23, 2004 at 09:56:31PM -0400, Carl Anderson wrote:
> > > 
> > > Is the current API creep in CVS intended?
> > > toGeometry(Envelope *, ... ) has changed and no long 
> > compiles against
> > > PostGIS cvs nor PostGIS 0.8.1
> > 
> > I've checked out JTS-1.4 and the change is there too, 
> > although not documented in the release notes and mismatching with the 
> > comment that preceedes its definition. I suppose it's a bug
> > in JTS ported to GEOS. Martin ?
> > 
> > > 
> > > I ask to see where I should try to plug bugs?
> > > 
> > > the CVS code is more delicate (has more instance of 
> > SIGABRTs) than the
> > > geos-1.0 code.
> > > 
> > > The CVS work has promising elements in it but while the 1.0 
> > code only 
> > > SIGABRT'ed on 15 of 200,000 geometries the CVS code 
> > SIGABRTs on more 
> > > than 200 of same set.
> > > 
> > > The 1.0 code only
> > >    SIGABRTs in the BufferOp routine
> > > and CVS
> > >    SIGABRTs in noding/IteratedNoder.cpp and strtree and other places
> > > but not BufferOp
> > > 
> > > remembe that my test set is by definition not unlimited and other
> > > instances of trouble may be waiting in both CVS and 1.0.
> > > 
> > > so should I chill and wait for CVs to settle, work on submitting a
> > > patch against 1.0 or work on CVS.
> > 
> > Current work on GEOS is focused on CVS, but if you found 
> > urgent bugs in GEOS-1.0 I think you should submit patches 
> > agains it too, in order to get a GEOS-1.1 release.
> > 
> > Could SIGABRTs have to do with exceptions ?
> > I'm asking because in cvs GEOS (as in jts-1.4) there is an 
> > exception mechanism used to reduce precision in case of 
> > rubustness-related topological errors, so while GEOS-1.0 
> > would throw an uncatched exception, GEOS-CVS would handle 
> > exceptions and try with a lower precision (on BufferOp).
> > 
> > > If the CVS API changes are intended could someone increment the 
> > > version
> > > tag (and directory name).
> > 
> > Let's wait for Martin response. It seems that the new 
> > interface lacks the ability of specifying the resulting 
> > geometry precision model, that will get the internal 
> > precision model... and this seems to me a bug.
> > 
> > --strk;
> > 
> > > 
> > > 
> > > C.
> > > 
> > > _______________________________________________
> > > geos-devel mailing list
> > > geos-devel at geos.refractions.net 
> > > http://geos.refractions.net/mailman/listinfo/geos-devel
> >