On Fri, Jul 29, 2011 at 12:42 PM, Paul Pfeiffer <nightdrift@...> 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
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
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
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
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
in this picture:
(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
contained in http://jira.codehaus.org/browse/GEOT-3634
Hope this helps
Ing. Andrea Aime
Via Poggio alle Viti 1187
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 962313