Hello Stephen
Le 09/11/2021 à 23:58, Stephen Mercado a écrit:
After upgrading to SIS 1.1, I observe that transformations to another
coordinate system will sometimes return points at (NaN, NaN), whereas
in SIS 1.0 they would throw a CoordinateTransformationError. Here is
an example that demonstrates the new behavior. I was expecting that
the old behavior would be kept, due to the documentation for methods
such as MathTransform.transform. I appreciate any information about
whether this is actually expected behavior, or a bug.
This is expected but of course can be questioned. There is a block of
comment in the source code explaining the rational [1]. Transform
implementations in Apache SIS try to follow a policy where NaN and
TransformException have two slightly different meanings:
* NaN means "value does not exist or is not a real number". This is
similar to the behavior of Math.sqrt(-1).
* TransformException means "value should exist but can not be
computed". For example because an iterative algorithm does not converge.
Above policy is specific to SIS; the GeoAPI interfaces does not said
anything about NaN. Of course there is also gray area between those two
cases (e.g. "value can not be computed /accurately/"), so feedback for
refining the policy are welcome.
The reason for allowing NaN numbers in SIS implementation is because we
may have a geometry were all points are at a reasonable distance from
the domain of validity, but where some envelope corners are too far. The
envelope corners are not points of the geometry (they are just
minimum/maximum), so the geometry is not wrong. But having the envelope
corners outside the domain of validity is a problem when we want to
transform the geometry envelope instead than the geometry itself. This
problem occurs more often near polar areas. Having NaN allows
Envelopes.transform(…) methods to decide if it is okay to ignore a
point. By contrast, according above policy an exception would mean "we
may miss something important if we ignore this point".
Comments for revisiting this policy are welcome, especially since this
is often gray area.
Martin
[1]https://github.com/apache/sis/blob/1.1/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/projection/TransverseMercator.java#L416
