[postgis-devel] Fwd: [MetaCRS] Inf in projection results

[Paul Ramsey]

FYI


---------- Forwarded message ----------
From: Charles Karney <charles.karney at sri.com>
Date: Tue, May 24, 2011 at 11:03 AM
Subject: Re: [MetaCRS] Inf in projection results
To: metacrs at lists.osgeo.org


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?

_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs