ED50-IGN.ES_to_WGS84 grid fallback can fail to be used properly

[ravenAtSafe]

In CS-MAP 13, if you reproject LL84(180,40) to ED50/ES.LL (using path ED50-IGN.ES_to_WGS84) you get 180,40 as your answer. This was not the case in CS-MAP 12.

I have traced this to three reasons:

1. Although the grid fallback is executed successfully, it produces a non-normalized LNG (1259.99... - close enough to 180 to be plausible).

2. CSdtcvt executes the subsequent transformation in spite of it being marked as NULL (there is even a commented out check that would prevent that).

3. CSgeoctI2 (like all iterative inverses?) is doomed to fail when it gets a non-normalized LNG (or LAT).

I think addressing issue 2 would be sufficient to restore CS-MAP 12 behavior, but it seems like the normalization issue might crop up all over the place.

[ravenAtSafe]

I now notice that even "null" xforms like Geocentric(0,0,0) might result in a change in coordinates if there is an ellipsoid change. So uncommenting the isNullXfrm check is probably a bad idea.

[Norm Olsen]

It appears that the real problem is that the iterative inverse, when close to the +/- 180 degree crack can generate wild results such as the 1259.9999 longitude value mentioned in the ticket. This is caused by a simple:

deltaLongitude = lng1 - lng2;

calculation when lng1 is +180 and lng2 is -179.9909 which produces a delta longitude of 360.0. This has escaped detection in common usage as there is not much geography at 180W longitude and in the datum shift business, these delta longitudes are rather small. Thus, you have to be really close to the crack to experience the problem.

NOTE: The line of code which tests for a NULL transformation method and which is commented out should be deleted all together. There is a specific transformation method with the "NULL Type" with a whole set of functions which do nothing. (They are very fast :>) I suspect that for some reason, the idea of just skipping NULL, as opposed to have some actual code which does a null transformation very fast, had a problem.

[Norm Olsen]

Corrected at version 2708. Added a new function to CS_angle.c, 'CS_lngEpsilon' which quickly calculates delta longitude with the retriction that the two longitudes are within a few degrees of each other. Perfectly suitable for the 2D iterative inverse functions where dalta longitudes are on the order of a fraction of a second. This correction was made to all transformations which implement the 2D iterative inverse transformation.