This is not totally correct. JTS does not check topology when
geometries are created. In fact, it deliberately avoids doing any
topology checks unless the user specifically requests them. Some
operations necessarily expect a certain level of topology to exist (e.g.
the overlay ops and spatial predicates assume OGC SFS topology, whereas
distance doesn't require much at all).
This was done deliberately to allow systems to input and hold geometry
which could be invalid, in order to allow it to be cleaned by further
processing.
The isValid() predicate does not throw an exception, it returns a
boolean indicating an error in topological validity. It was meant as a
simple pass/fail check, and was not intended to be a full topology error
analysis tool. It is possible to get a text description of the
particular failure. It would be possible to extend the IsValid class to
support returning multiple errors (and locations) when they can be
detected. In my experience it's not possible to determine *all* errors
in a single pass, since some kinds of errors "mask" others (i.e. are so
egregious that they prevent further error detection being performed, or
cause them to be misinterpreted).
Alvaro Zabala wrote:
The problem is that OpenJUMP uses JTS as geometry model, and JTS is a
restrictive geometry model, based in SFS OGC specification.
This specification says "polygons shells must not have
self-intersections", so when JTS finds this kind of geometry launchs
an exception (TopologyException).
Other projects, like gvSIG, Geotools, etc. use a less restrictive
geometry model: Java2D, for rendering geometries. So when the
persistence driver reads a self-intersecting polygon shell, it doesnt
create a JTS polygon, it creates a Java2D GeneralPath, geometry model
which allows self-intersecting polygons.
In my opinion, one of the points where JTS could improve in this
subject is not to "short-cuit" validation in isValid() geometry
method. This method, when find an error, launchs an exception, so you
need many iterations to correct a geometry at all.
I have developed a Quality Assurance library for gvSIG project:
libTopology [1], to ensure topological correctness with a rule based
model. Im planning to port this library to GeoAPI (in medium term, not
before the final of 2009 for overworking :( ), to allow geometry
validations. I have desglosed all isValid validations in multiple
steps [2]. This, of course, is only a proof of concepts.
[1] libTopology.
http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/
[2] Decompsing isValid().
http://subversion.gvsig.org/gvSIG/trunk/libraries/libTopology/src/org/gvsig/topology/topologyrules/JtsValidRule.java
2009/2/12 Tuure Laurinolli <[email protected]
<mailto:[email protected]>>
Sunburned Surveyor wrote:
Tuure,
You wrote: "...OpenJUMP doesn't deal with some oddly broken
geometries..."
What are you trying to do with these geometries and how are
they broken?
With OpenJUMP I was trying to see if the invalid geometries were
important enough to be salvaged, or if I could just drop them.
This was part of preprocessing to get a Shape reader to accept
them for conversion into a proprietary format. The converter read
even the invalid geometries in fine, but at later stages of
conversion there were problems - thus I had to find and either
drop or fix invalid geometries in the early stages of conversion.
Usually the problematic geometries had self-intersections and
duplicate points, but some were stranger and had e.g. those
inverted rings I mentioned before.
_______________________________________________
jts-devel mailing list
[email protected]
<mailto:[email protected]>
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Alvaro Zabala Ordóñez
azabala[en]gmail[punto]com
alvaro.zabala[en]juntadeandalucia[punto]es
Tlf: 954 995 572
Gabinete de Normalización y Calidad
Servicio de Coordinación y Desarrollo de Sistemas Horizontales.
D.G. de Innovación y Administraciones Públicas.
Consejería de Innovación, Ciencia y Empresa, Junta de Andalucía
------------------------------------------------------------------------
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
