<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2024 at 10:10 AM Kristian Evers <<a href="mailto:kristianevers@gmail.com">kristianevers@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Roger,<div><br></div><div>I believe using proj_factors() is the fastest way, yes. The current implementation has its roots in the very early days of PROJ.</div><div>If we were to implement the same functionality from scratch today they would likely be split into more smaller functions with</div><div>one purpose each. You could always implement your own custom version of it based on the PROJ code. Start here: </div><div><a href="https://github.com/OSGeo/PROJ/blob/master/src/factors.cpp" target="_blank">https://github.com/OSGeo/PROJ/blob/master/src/factors.cpp</a></div></div></blockquote><div> </div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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</div><div>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</div><div>got a grid north that can deviate from true north. Also, EPSG:4326 is not SWEREF99 - it is the WGS84 datum ensemble given</div><div>in geodetic coordinates. You are probably looking for one of the SWEREF99 TM CRS’s.</div></div></blockquote><div><br></div><div>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'.</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>The meridian convergence calculation should work for most, if not any, projected CRS.</div></div></blockquote><div><br></div><div>Great!<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Roger Oberholtzer</div></div>