Hi Andrea,
hope you feel better today :-)
On Thu, Feb 12, 2015 at 8:04 AM, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Wed, Feb 11, 2015 at 11:43 PM, Stefano Costa <ridethepeng...@gmail.com>
> wrote:
>
>>
>>
>> ...and now I see a flood of exceptions in the log, but rendering never
>> stops! :-)
>>
>
> And keeps on reporting errors in a continous stream? Either it's stuck or
> there is a whole lot of them.
>
No, I'm not seeing a continuous stream of errors. Sorry, "flood" is too
strong a word :-) What I meant to say is that every time I zoom/pan the map
(i.e. a new RenderingTask is launched), a new exception appears in the log
for each invalid geometry within the map extent. In the dataset provided by
Ron, there are 9 geometries that cannot be constructed, so I'm seeing up to
9 new exceptions on each zoom/pan. Everything works as expected: exceptions
are logged, the renderer skips invalid geometries and keeps rendering valid
ones.
>
>> Anyway, the person who reported the issue doesn't say anything about the
>> context in which he sees that rendering is stopped (is it a web app calling
>> GeoServer's WMS service? is it a standalone Swing application using
>> JMapPane?), so I don't know if we're talking about RenderingTask or
>> RenderExceptionStrategy...
>> or some other RenderListener implementation I'm not aware of.
>>
>
> Ron definitely uses GeoServer.
>
I published the data with GeoServer (after a bit of a struggle with the
layer's projection - SRID:90112...) and I could see no image in the layer
preview (lots of IAE in the log, which no doubt stopped the rendering).
Then, I patched RenderExceptionStrategy adding IAE to the list of ignored
exceptions and... lo and behold, I could see a nice map in the layer
preview (still plenty of exceptions in the log, of course)! :-) So,
definitely that is the listener which calls renderer.stopRendering().
>
>
>>
>>
>> In any case, I'm still convinced that a more meaningful exception should
>> be thrown in case an invalid geometry is read and then implementations of
>> RenderListener will be able to make an informed decision on what to do with
>> it (basically, either ignore it or quit rendering). Testing if the
>> exception is an instance of IllegalArgumentException seems to me too prone
>> to error.
>>
>> Any further thoughts?
>>
>
> I still think the best course of action is to fix the geometries, skipping
> all the invalid ones (according to JTS) will not
> make Oracle users happy, because to them those same geometries are valid
> and should be rendered/returned by
> JTS.
>
Well... actually, if I'm not mistaken, these troubling geometries are NOT
valid also on Oracle's own terms. If I run
sdo_geom.validate_geometry_with_context against them, I get error code
13343 (a polygon geometry has fewer than four coordinates). So, I don't see
why we should feel compelled to render geometries that are not valid even
according to Oracle itself.
Anyhow, for this particular case, the fix was trivial (luckily): in method
SDO.createLinearRing(), I simply added a call to
CoordinateSequences.ensureValidRing() before invoking LinearRing's
constructor. That should deal with polygons with less than 4 coordinates as
well as open polygons (error code 13343 and 13348 respectively).
You can inspect the code here
<https://github.com/ridethepenguin/geotools/commit/a3182cb9468d8e241f75b1427ce4a1852b74779f>
.
>
> Cheers
> Andrea
>
Thanks for your help,
--SC
------------------------------------------------------------------------------
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
