Re: [Geographiclib-users] Projecting ECEF into UTM

[Charles K. <cha...@sr...>]

On 2014-01-10 11:58, Ben Adler wrote:
> Charles,
>
> brilliant! Thank you for these quick and helpful answers! I tried
> implementing them, here's my problems:
>
> Why do the GeographicLib::UTMUPS::Forward/Reverse method not use const
> for input parameters? That breaks a lot of my code. Of course I could
> make relevant members mutable or use const_cast, but that seems weird.

Please give an example for code that your compiler rejects.  I believe
that

     static void Forward(real lat, real lon, ...) { ... }

has the same signature as

     static void Forward(const real lat, const real lon, ...) { ... }

(I.e., the const says how lat/lon can be used inside the function but
nothing about what happens outside the function.)

> Now that I have the EPSG code, I need to get the WKT. Grepping for wkt
> in the GeographicLib sources didn't yield any results, so I guess I need
> to search and extract the relevant line from EPSG2WKT.TXT (google-hit at
> geospatialpython) myself?
>
> Comparing that file with the WKT from http://spatialreference.org, the
> text file seems to be missing the AXIS-entries. Also, of course, the
> height information is missing. Maybe it's out of GeographicLib's scope,
> but I wonder how exactly the WKT for e.g. UTM 11N with height above the
> WGS84 ellipsoid in meters should look like.

Probably the AXIS entries are optional?  These EPSG codes deal only with
the horizontal axes.  There are separate (less well established)
conventions for the vertical datum.

> Why does GeographicLib::UTMUPS::EncodeEPSG(11, true) return 32610?
> Shouldn't it be 32611 (http://spatialreference.org/ref/epsg/32611/)?

That's a careless bug.  Please apply the attached patch.  (Only the part
affecting EncodeEPSG is essential.) Thanks for catching this.

   --Charles