Alvaro:
Some observations and explanation:
- SnapIfNeededOverlayOp is really only intended for situations where the
arrangement of vertices and lines is such that the JTS noding
functionality fails to produce a correctly noded result. In this case,
a heuristic of snapping geometries together using a *small* tolerance
often allows the computation to be carried out robustly (ie. completes
with a reasonable answer). It is *not* intended as a general purpose
way of snapping geometry together.
- The idea behind the JTS PrecisionModel is that it informs JTS of the
precision model of the input data. JTS uses this PrecisionModel in its
internal computation, and ensures that any geometric output will also
obey the same precision model. The key point here is that all input
obey the supplied precision model. This is the client's responsibility
to ensure is the case. In the example you give, it is not correct to
supply the ordinate value of 479.999 with a PrecisionModel of
Fixed(1.0). (Often JTS is resilient to data with illegal precision, but
not always...)
So, what this means is that you may well be getting output which seems
illogical, but since your input is illegal and you are using a class for
purposes for which it wasn't really intended, there doesn't seem to be
much value in speculating about what the answer "should be".
I'd be interested to hear about the semantics and use case for the
snapping code that you've implemented.
As for averaging coordinates, the approach I used in the snap-rounding
code was to NOT average coordinates, on the theory that it was better to
use coordinates from the input data, rather than computing new ones.
Also, any averaged coordinates would still have to obey the precision
model - which would probably mean that they ended up "snapping" to one
of the inputs anyway.
Martin
Alvaro Zabala wrote:
Hi,
Im trying snap overlay capabilities of JTS 1.8, and Im getting a
strange result (or its possible I dont understand well the concept of
"PrecisionModel").
The code is:
String wktLS1 = "LINESTRING (260 120, 300 180, 420 180, 480 120)";
String wktLS2 = "LINESTRING (479.999 120, 459 114, 437 128, 426 130,
458 141)";
GeometryFactory factory = new GeometryFactory();
WKTReader wktReader = new WKTReader(factory);
Geometry ls1 = wktReader.read(wktLS1);
Geometry ls2 = wktReader.read(wktLS2);
Geometry intersection = SnapIfNeededOverlayOp.intersection(ls1, ls2);
System.out.println(intersection.toText());
and the result is:
LINESTRING (479.999 120, 480 120)
With a default PrecisionModel, result is GEOMETRYCOLLECTION(EMPTY)
(correct),
With a PrecisionModel of factor = 1 result is MULTIPOINT (458 141,
480 120)
Please, correct me if Im wrong, but in a snap environment they
(479.999 120, 480 120) must be consideered the same point, dont they?
When JTS didnt have snap capabilities, I developed a snap overlay
stuff, by extending (LineIntersector, PlanarGraph, PointLocator,
PolygonBuilder,etc. etc.) to work with snap concepts (including a
SnapCoordinateMap). This code will be available in the next release of
gvSIG, but only compiles with JTS 1.7. If someone wants to probe it,
Ill send it by mail.
I say this because my snap overlay version, the result with a snap
tolerance of 0.001d is POINT (480 120). that is: it consideer them the
same point.
Another question; would be better for snapping to compute an average
coordinates?
If we compute an overlay, the result is 480,120, but one of the
geometries dont have this exact point may be confusing.....or maybe we
would must to snap coordinates between geometries before computing an
overlay?
Sorry If all of this looks unclear.....
Thank you very mutch and best regards.
Hi, sometime ago I developed a Snap Overlay operation by extending
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
_______________________________________________
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
