<div dir="ltr"><div dir="ltr">This is just a guess based on what I remember from the implementation.</div><div dir="ltr"><br></div><div>if it has the "+type=crs", it would be understood as a CRS (makes sense). In that case, it creates some auxiliary objects to compute the transformation from the geographic to the projected, and call itself with that transformation (yes, it is a recursive call).</div><div>Apparently the creation of those auxiliary objects to generate the transformation is more expensive than the computation of the factors themselves (it makes sense: the computation of the factors is "just" some mathematical operations, that the CPU can do very efficiently. Creating objects is something else).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 25 Oct 2024 at 10:51, Roger Oberholtzer <<a href="mailto:roger.oberholtzer@gmail.com">roger.oberholtzer@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">On Fri, Oct 25, 2024 at 10:31 AM Thomas Knudsen<br>
<<a href="mailto:knudsen.thomas@gmail.com" target="_blank">knudsen.thomas@gmail.com</a>> wrote:<br>
><br>
> >  If I use something defined with proj_create_crs_to_crs I get incorrect<br>
> values for the meridian convergence<br>
><br>
> Which is as expected: proj_create_crs_to_crs returns a transformation<br>
> BETWEEN two CRS. The geometrical factors are meaningfully defined<br>
> for projections only. A transformation between two CRS is not in general<br>
> a projection.<br>
><br>
> You may get some numbers out of calling proj_factors with a transformation<br>
> as an argument, but you should not expect any kind of meaningful result.<br>
><br>
> Also, you may get numbers out of a PJ generated from a CRS (EPSG:nnnn),<br>
> by ignoring the reference frame information implied, in which case an<br>
> eventual projection remains. But if the CRS is, say, geographical or<br>
> geocentric cartesian, the factors are meaningless.<br>
><br>
> **It's apples and pears**. Don't expect meaningful proj_factors from anything<br>
> other than a traditional projection specification.<br>
<br>
I'm fully with you. And making a general implementation of this is<br>
what I am trying to accomplish. The calculation time of proj_factors<br>
when the spec includes +type=crs is the current issue. When I define<br>
things with, say:<br>
<br>
   proj_create("EPSG:5678")<br>
<br>
The proj_factors call takes over 60x longer (exact timing difference<br>
to be reported soon) than for:<br>
<br>
   proj_create("+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000<br>
+y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7<br>
+units=m +no_defs")<br>
<br>
The second is the proj string from projinfo for EPSG:5678 - minus the<br>
+type=crs. I purposely left all the perhaps not needed items to<br>
demonstrate that it is the +type=crs that is the time culprit. I<br>
should add that in either case, the actual meridian convergence value<br>
is the same. But taking 15 hours instead of 15 minutes to make a point<br>
cloud is prohibitive. Hence my investigation.<br>
<br>
Your point on where the meridian convergence is going to be a<br>
meaningless value are understood. How to restrict this to valid<br>
projections is next up on my todo list.<br>
<br>
-- <br>
Roger Oberholtzer<br>
</blockquote></div></div>