On Thu, Feb 12, 2015 at 3:38 PM, Stefano Costa <ridethepeng...@gmail.com>
wrote:
> Hi Andrea,
> hope you feel better today :-)
>
>
Somehow... not good yet, but better.
>
> 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.
>
Right, that is annoying but acceptable (that's why we have a built-in limit
of 1000, after those they are way too many to log).
>
>
>>
>>> 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().
>
>
Good.
>
>>
>>>
>>>
>>> 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>
> .
>
>
Yep, that works, allows to display everything, and will work also in WFS
where there is no tolerance. Can you please add a test?
As for your previous suggestion, it makes sense too, but
IllegalArgumentException is too generic... maybe we could create
a GeometryParsingException (which extension IOException) that the ignorable
exception listener could learn to ignore,
and the OracleDialect could turn any failure calling SDO into one of those.
Just a though... the better solution is to fix the geometry parsing (user
data is sacred, software that does not handle it
is just tossed away most of the time), but also having this one as an
addition would not hurt.
Cheers
Andrea
--
==
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
