[postgis-devel] Fwd: [MetaCRS] Inf in projection results
pramsey at opengeo.org
Tue May 24 13:03:14 PDT 2011
---------- 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)
-90 0 -> inf inf (or maybe inf 0 or -inf 0 or whatever)
inf 0 -> nan nan
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
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
MetaCRS mailing list
MetaCRS at lists.osgeo.org
More information about the postgis-devel