On Fri, Jul 29, 2011 at 12:42 PM, Paul Pfeiffer <[email protected]> wrote:
> So... what I can't figure out is.... Does the maths transform of each
> point result in some of the points falling off the edge? (180.04999,
> -90) ==> (0.4999, -90)
> Or... have I just missed the boat completely?
The first important thing to understand is that while related, this is
a different problem, so you're putting yourself on a cross trying to
solve two orthogonal issues as the same time.
The one reported in GEOT-3634 is the lack of densification and boundary
checks, this one is a numerical instability in the boundary checks instead.
Let's address one at a time.
The conversion of (180, 89,9) from WGS84 to NAD83 unfortunately
results in (-180, 89.9), there is nothing I can do about this, the two
geoids are slighly off and -180 in one results in 180 in the other due
to a tiny rotational factor (and the fact that coordiantes in degree at
the dateline flip from one side to the other at the minimal disturbance)
This puts off the transformation enough that you don't get the
whole world back in the other datum.
A solution for this particular case is to stay a bit away from the borders
when checking for boundary conditions at line 1372 in the CRS class:
final double v1 = axis.getMinimumValue() + 1e-12;
final double v2 = axis.getMaximumValue() - 1e-12;
This makes your test pass, with the result being:
GeneralEnvelope[(-180.0, -90.0), (179.999999999999, 89.90000000000327)]
The original issue in GEOT-3634, and in
http://jira.codehaus.org/browse/GEOT-3570,
which is the parent issue, are different in nature.
The issue that started this all GEOT-3570, is that all coverage
related code uses
GeneralEnvelope transform(final MathTransform transform, final
Envelope envelope),
which does not know enough to check boundary conditions and always
fail to handle
boundary conditions (whole world case).
One solution would be to modify all coverage code to use
GeneralEnvelope transform(final CoordinateOperation operation, final
Envelope envelope)
instead, this one has the CoordianteOperation which has enough
information to do the
world boundary checks.
I would have gone down that way but Jody suggested that instead we could have
Envelope mimick
ReferencedEnvelope.transform(CoordianateReferenceSystem, lenient)
instead, and then modify all coverage handling code to use that one (otherwise
we won't solve GEOT-3570)
Fair enough, doing that also allows us to do densification, which
would increase the
precision of the transformation from the "point by point" to the
"densified" case
in this picture:
http://jira.codehaus.org/secure/attachment/55460/ReprojectEnvelope.png
(which is not 100% equal to the real thing, but gets very close).
This is what http://jira.codehaus.org/browse/GEOT-3634 is about.
So for the problem you're reporting I'd add yet another issue, it's in
the same area of
code, but the problem is of different nature is actually orthogonal to
the changes
contained in http://jira.codehaus.org/browse/GEOT-3634
Hope this helps
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
