On Wed, May 21, 2014 at 12:49 PM, Michael Michaud <m.michael.michaud@orange.fr> wrote:
Hi,
Unfortunately there's no rule or metric about which operations will fail on invalid geometry.  It all comes down to the details of the algorithm.  For instance, overlay ops are likely to fail, whereas buffer is relatively robust (although with the caveat that for an invalid geometry the result may not be what is "expected").  In some cases this is noted in the Javadoc.
From my experience, TopologyException are also more likely to happen while working with an integer PrecisionModel than with the double precision model.

Yes, I've notice this too.  This is likely because rounding computed intersections tends to move them across nearby line segments, thus corrupting topology.  The solution for this is to use Snap-Rounding (which has an implementation in JTS, but is not yet used in the overlay computation. 

The bottom line is that geometry passed to any non-trivial JTS operation should be known to be valid. There is a performance hit for doing this, for sure.  Perhaps an even bigger issue is: what do you do with an invalid geometry?  (Of course there are various heuristic ways of cleaning it up, but in general this is context-dependent).  Generally it's best to ensure validity as early as possible in the system, so that subsequent processing can proceed robustly.  That's why JTS leaves the question of when to do validity checking to the client, since only they can know when it is appropriate and efficient to do it.
A clear separation between validating and processing geometries is probably a good thing. What is a bit frustrating for the user is that JTS does not offer much tools to fix invalid geometries before processing. I agree that there is not always one way to fix invalid geometries, but even when the user knows what he wants, the work to do it may be tedious. From my experience, the most frequent problems are :
- polygon with self-intersecting rings
    most obvious solution : noding the rings and creating a MultiPolygon
    doing it with JTS is difficult
- linestring with two identical points
    most obvious solution : creating a Point
    doing it with JTS is not difficult
- multipolygon with overlapping polygons
    no obvious solution : merging ? making hole when possible ?
    creating several features ?
- polygon with less than 4 points
    most obvious solution : creating a LineString or even a Point
    doing it with JTS is not difficult
...
Don't know what postgis ST_MakeValid does exactly, but a method to solve the first case would be great in JTS.

My 2 cents,

Michaël

Thanks for this summary, Michael. Agreed, an equivalent to PostGIS' ST_MakeValid would be a nice addition to JTS.  It's a non-trivial amount of work, though.