<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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">https://github.com/OSGeo/PROJ/blob/master/src/factors.cpp</a></div><div><br></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><br></div><div>The meridian convergence calculation should work for most, if not any, projected CRS.</div><div><br></div><div>/Kristian<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 25 Mar 2024, at 08.44, Roger Oberholtzer via PROJ <proj@lists.osgeo.org> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div>I have been using proj_factors() to get the meridian convergence for a given point. It has been working great. We need this when projecting LiDAR points that involve multiple rotations. The code is something like this:</div><div><span style=""><br></span></div><div><span style="font-family: monospace;"><span style="background-color:rgb(48,48,48)"> <span style="background-color:rgb(255,255,255)"> PJ_FACTORS factors;</span></span><span style="background-color:rgb(255,255,255)">
</span><span style="background-color:rgb(255,255,255)"><br> PJ_COORD vals;<br></span></span></div><div><span style="font-family: monospace;"><span style="background-color:rgb(255,255,255)"><br></span></span></div><div><span style="font-family: monospace; background-color: rgb(255, 255, 255);"> vals.lp.lam = DegreesToRadians(point->LONGITUDE);
<br> vals.lp.phi = DegreesToRadians(point->LATITUDE);
<br> <br> factors = proj_factors(tinfo->Meridian, vals);
<br>
<br> <span style="font-weight:bold">return</span>(RadiansToDegrees(factors.meridian_convergence));<br></span></div><div><br></div><div>I have been using it with Sweref99 (EPSG:4326).</div><div><br></div><div>I have two questions:</div><div><br></div><div>Is proj_factors() the fastest way to get this information? A look at the code shows that it is calculating other things as well. Is there is a faster way? When generating point clouds, each contains 10s of millions of points, and we generated 10s of thousands of these over a summer. Needless to say, we are always looking for speedups.<br></div><div><br></div><div>Would this method work for all 'standard' projections? By 'standard' I mean the typical ones used in, say, European countries. Would we need to consider anything when extending this to something other than EPSG:4326?<br></div><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Roger Oberholtzer</div></div></div>
_______________________________________________<br>PROJ mailing list<br>PROJ@lists.osgeo.org<br>https://lists.osgeo.org/mailman/listinfo/proj<br></div></blockquote></div><br></div></body></html>