Transforming from NAD83 to NAD27 might produce an invalid result (INF/INF) if the coordinate is near to the grid's coverage boundary

[baertelchen]

When transforming a LL value from NAD83 to NAD27 (which is an inverse of the NADCON datum shift) and that coordinate is near to the grid coverage's boundary, the inverse transformation might produce a return value of INF/INF.

[baertelchen]

Fixed in changeset 2192

The main problem had been an invalid grid-cell-check in CS_nadcn.c where the target grid cell is being retrieved.
In case the LL coordinate was very close to the grid coverage's boundary (e.g. latitude of 50.000019517393198), the code in CSextractNadconFile() incorrectly found a "cell" that was beyond the actual coverage thus messing up the calling inverse transformation sequence.

The check was this:

if (eleNbr >= (thisPtr->elementCount )

recNbr >= (thisPtr->recordCount))

{
...warning...
}

but should have been (and is now) that:

if (eleNbr >= (thisPtr->elementCount - 1)

recNbr >= (thisPtr->recordCount - 1))

{
...warning...
}


because (thisPtr->elementCount - 1) is the actual number of valid records or elements, respectively. (eleNbr and recNbr are 0-based indexes)

Note that this submission contains an additional [CS_deltaLongitude] method which returns the relative longitude to a given base meridian.
This method handles the special cases where the relative logitude value is antipodal to the given base meridian or the calculation somehow passes the -/+ 180° boundary crack.

This new [CS_deltaLongitude] is called by the CSnadcnI2() function.

Submitting on behalf of Norm.