[PROJ] Meridian convergence

[Roger Oberholtzer]

On Mon, Mar 25, 2024 at 10:10 AM Kristian Evers <kristianevers at gmail.com>
wrote:

> Roger,
>
> I believe using proj_factors() is the fastest way, yes. The current
> implementation has its roots in the very early days of PROJ.
> If we were to implement the same functionality from scratch today they
> would likely be split into more smaller functions with
> one purpose each. You could always implement your own custom version of it
> based on the PROJ code. Start here:
> https://github.com/OSGeo/PROJ/blob/master/src/factors.cpp
>

I think I originally looked there when looking for a solution. IIRC it
wasn't obvious to me which bits to pick out for a potentially quicker
calculation. I may revisit this.


> I doubt that your code is particularly useful, to be honest. If your are
> indeed using EPSG:4326 I believe you will get a meridian
> convergence of 0.0 no matter what the input. The reason being that
> EPSG:4326 is not a projected CRS and hence you haven’t
> got a grid north that can deviate from true north. Also, EPSG:4326 is not
> SWEREF99 - it is the WGS84 datum ensemble given
> in geodetic coordinates. You are probably looking for one of the SWEREF99
> TM CRS’s.
>

In fact I do get a value. And it has a significant impact on our results.
We have two high resolution LiDAR units at 90 degrees to each other. If one
looks at something like a lamp post that was measured by both, without the
convergence value, the lamp post appears to split in two towards the top.
That is because we use the orientation from the GPS IMU for the point
rotations. Without the convergence, we are trying to use orientations with
a different origin (GPS IMU vs Sweref99 projection). We are very happy with
the results after we sorted this 'minor detail'.

The convergence sign matches the location of the GPS receiver's location
relative to the origin of Sweref99. Negative on one side, and positive on
the other. So there is even observable validity of the values.

The meridian convergence calculation should work for most, if not any,
> projected CRS.
>

Great!

-- 
Roger Oberholtzer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240325/20fc4902/attachment.htm>