On Wed, May 21, 2014 at 12:49 PM, Michael Michaud <
[email protected]> 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.
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Jts-topo-suite-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
