On Tue, Sep 25, 2012 at 2:43 PM, David Doria <daviddoria@gmail.com> wrote: <snip code>
Here you see asin(z) . asin() requires the argument to be [-1,1] (http://www.cplusplus.com/reference/clibrary/cmath/asin/). However, this should just be the z component of any Cartesian point right? Is there some restriction on the input Cartesian point to cartesian_to_spherical_equatorial2 (and hence the from_cartesian_3_to_spherical_equatorial_2 strategy)?
I see a restriction on from_cartesian_3_to_spherical_polar_2:
\note If x,y,z point is not lying on unit sphere, transformation will return false
but I don't see the same restriction on from_cartesian_3_to_spherical_equatorial_2. Additionally, it doesn't seem to just be a missing comment because the transform() call actually returns true even though this point is not on the unit sphere. If I normalize the point and call the function:
CartesianType cartesian(-0.94862, -0.22167, -0.22580);
The conversion seems to work successfully, and the call still returns true.
Any thoughts? Is this a bug? If not, why is the function not returning false? And better, shouldn't this condition have at least an assertion (i.e. if the norm != 1, then return false or throw)?
I'm sure Barend will comment on the Geometry library's implementation, but my general thoughts pertaining to this particular transformation are that the library *should* assume a normalized Cartesian coordinate since that won't cause performance issues to users already dealing with normalized coordinates. If this is indeed what Barend had in mind for a precondition then perhaps an assert that the magnitude was near 1, like you suggest, would be helpful. If the user isn't dealing with normalized coordinates then he probably wants an end result of the lat/lon and the altitude, which would be the magnitude of the Cartesian coordinate he already had before normalization minus the altitude of the Earth at the returned location. --Michael Fawcett