<div dir="ltr">Roger,<div><br></div><div>The "factors" elements refer to a projection, not to a CRS</div><div>(the CRS includes reference frame information), and not</div><div>to a transformation (which describes a path between two</div><div>different CRS).</div><div><br></div><div>So you should only call proj_factors on a PJ object obtained</div><div>from a plain classic proj(ection) string, i.e:</div><div><br></div><div>p = proj_create(0, "proj=utm  zone=33  ellps=GRS80");</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors. 24. okt. 2024 kl. 14.11 skrev Roger Oberholtzer via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I have been using proj_factors in a couple CRS to get the<br>
median_convergence value. I need this when rotating a point that has<br>
been projected into the CRS.<br>
<br>
In my usual setup, I define something like the following (WGS84 (from<br>
a GPS receiver) to Sweref99):<br>
<br>
proj_normalize_for_visualization(0,<br>
                                       proj_create_crs_to_crs( 0,<br>
                                                               "EPSG:4326",<br>
                                                               "EPSG:3006",<br>
                                                               0))))<br>
return(ISERROR);<br>
<br>
This works fine. I get the points I expect. But as I will need to<br>
rotate that point using data from the GPS (heading is true north), I<br>
need to know how that differs from the projected point's north. So I<br>
use proj_factors. As it turns out, I cannot use the definition from<br>
above to do this. The median_convergence value is wrong. So what I<br>
have been doing (for EPSG:3006 - it is CRS-specific) is defining<br>
something like this:<br>
<br>
proj_create(0, "+proj=utm +zone=33 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0<br>
+units=m +no_defs");<br>
<br>
You will note that this is the implementation of EPSG:3006, but<br>
without +type=crs. Why without that parameter? Time. When including<br>
it, the proj_factors call takes around 60 times longer. This is<br>
extremely significant when generating, say, point clouds with hundreds<br>
of million points. A processing time of 15 minutes becomes 15 hours.<br>
The values provided are exactly the same. But one takes significantly<br>
longer to provide them.<br>
<br>
I see this effect in more than EPSG:3006. For example EPSG:5677. I<br>
suspect that it is generally the case.<br>
<br>
What I would like to do is something like this:<br>
<br>
proj_normalize_for_visualization(0,<br>
                                       proj_create_crs_to_crs( 0,<br>
                                                               "EPSG:4326",<br>
                                                               "EPSG:3006",<br>
                                                               0))))<br>
return(ISERROR);<br>
<br>
proj_create(0, "EPSG:3006");<br>
<br>
<br>
Where the first is used to project the point, and the second is used<br>
to call proj_factors for that point.<br>
<br>
This would allow a general solution, which is what I am after. So I<br>
either need to call something other than proj_create, or I need to see<br>
how to remove +type=crs in this context.<br>
<br>
Does this make sense?<br>
<br>
-- <br>
Roger Oberholtzer<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>