[MetaCRS] Inf in projection results

[Charles Karney]

I recommend treating inf and nan in the spirit of IEEE floating point:

E.g., with polar stereographic (center at N pole)

Forward:
   -90 0 -> inf inf (or maybe inf 0 or -inf 0 or whatever)
   inf 0 -> nan nan

Reverse
   inf inf -> -90 0 (I suppose this could be -90 nan?)

I recently attempted to make GeographicLib "do the right thing" with
such inputs.  This entailed:

* reading the numbers "nan", "1.0QIND", etc. correctly.
* fixing some of the tests, e.g., lat > 90 and !(lat <= 90) are no
   longer the same.
* inventing a UTM zone and MGRS code for nan (I picked "INV" and
   "INVALID").

Other that this these stranged numbers just percolated through the code
and the appropriate strange numbers comes out the other end.

An application is projecting a set of coordinates using "nan nan" as a
marker for the end of a line segment (e.g., coast outlines).  This is
compatible with the way Matlab reads numbers and plots lines.

On 05/24/11 13:36, Paul Ramsey wrote:
> Hi All,
>
> We've recently run into a problem with a transformation returning Inf
> coordinates... when passed further down the processing chain to GEOS,
> algorithms go into infinite loops. So question: should the possibility
> of getting back Inf results be something we should expect when running
> a proj4 transform (in this case it was going from a planar to 4326, so
> the Inf value was even more surprising to me)?
>
> And following on with a non-projection-related query: if you as a
> geometry processing routine got handed a geometry with Inf
> coordinates, what would you do? Give up? Coerce them into something
> else?