Hi Stefano,
sorry for the late reply, I'm stll stuck in bed with fever...
Anyways, the streaming renderer is built to be tolerant to errors, the code
looks as follows:
try {
painter.paint(graphic, shape, style, scale, labelObstacle);
} catch(Throwable t) {
fireErrorEvent(t);
}
So you can see each and any exception is caught and does not stop the
rendering per se.
What can stop the rendering are the listeners that get the error message,
there
is one in GeoServer, WMS module, RenderedImageMapOutputFormat class (going
by
memory, no IDE in front of me) that counts how many errors happened, and
stops
the renderer by calling stopRendering() when there are more than a admin
configurable
threshold.
The default value for that threshold is 1000, so either you have more than
1000 failures,
or something is not working as it should in the code that handles the error
count.
And oh, there is also a time based check, rendering is stopped by default
after 60
seconds, againt something tunable and happening in that GeoServer class,
which
you probably want to raise to a number more suitable to debugging.
If there are indeed more than 1000 failures, maybe the fix should not be
done here,
but in the Oracle reader, recognizing that Oracle is happy to store broken
geometries,
and trying to do something to fix them before turning them into JTS
geometries.
In this case the class you want to look at is SDO, in the gt-jdbc-oracle
module
Hope this helps
Cheers
Andrea
On Wed, Feb 11, 2015 at 6:38 PM, 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
>
>
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
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
