[geos-devel] Current Status

[Martin Davis]

> 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?


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
>