I kind of like your approach Stefano, I am fond of graceful failure. Right
now we fail so we can report an error. As long as your patch logs the
featureId with the problem for the sys admin to see we are probably good
(perhaps at level FINE).
You consider turning this on with a query hint along the lines of
SKIP_INVALID?
This would give StreamingRenderer a chance to behave in a kind fashion,
while WFS can reliably produce a failure. Not all protocols can support
this grateful failure, for example WFS should fail hard if it is unable to
write out a valid GML Geometry.
--
Jody
--
Jody Garnett
On 11 February 2015 at 12:38, Stefano Costa <ridethepeng...@gmail.com>
wrote:
> Dear GeoTools developers,
> I'm attempting to tackle issue GEOT-4885: GeoTools stops rendering valid
> geometry elements after an invalid geometry element
> <http://jira.codehaus.org/browse/GEOT-4885> and, since I'm pretty much a
> newbie here, I need guidance as to how to solve it sensibly.
>
> The issue reporter laments that GeoTools stops rendering features in a
> collection when an element with invalid geometry is found and provides
> sample data to reproduce the error, which I did. In this particular case,
> the culprits are several polygon geometries with less than 4 points: this
> causes the
> method com.vividsolutions.jts.geom.LinearRing.validateConstruction() to
> throw a java.lang.IllegalArgumentException and the rendering process to
> stop.
>
> I devised a very naive fix
> patching org.geotools.renderer.lite.StreamingRenderer.drawPlain()
> and org.geotools.renderer.lite.StreamingRenderer.drawOptimized() methods:
> basically what I do is to catch the IllegalArgumentException, log it and
> keep going with the rendering process. You can take a look at the code
> here:
> https://github.com/ridethepenguin/geotools/commit/0672a765d334018b3ec4bebd9d0d7d6cc0124dc2
>
> I realize this is a very naive approach, which makes the totally
> unwarranted assumption that any IllegalArgumentException thrown by the code
> inside the try-catch block is due to an invalid geometry being constructed.
> A more sound approach would require, I believe, to have a custom exception
> type (something along the lines of InvalidGeometryException) be thrown by
> "geometry builders" and dealt with accordingly by client code.
>
> Now, how to do that sensibly? ;-)
>
> Proposals:
>
> 1. patch com.vividsolutions.jts.geom.GeometryFactory: I guess this
> cannot/should not be done, as the class is part of the JTS library
> 2. patch every single implementation of
> org.geotools.data.FeatureReader: implies touching quite a few classes, but
> I guess it's feasible
> 3. ...any better ideas?
>
>
> Thanks for your help,
> Stefano Costa
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
