<div dir="ltr"><div><a href="https://proj.org/en/9.5/development/reference/functions.html#c.proj_factors">https://proj.org/en/9.5/development/reference/functions.html#c.proj_factors</a></div><div>You just provide the projected CRS, just created from the EPSG code. It converts it internally into the projection over its geographic.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 24 Oct 2024 at 15:19, 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 Thu, Oct 24, 2024 at 2:36 PM Javier Jimenez Shaw <<a href="mailto:j1@jimenezshaw.com" target="_blank">j1@jimenezshaw.com</a>> wrote:<br>
><br>
> The last versions also accept a projected CRS, extracting the projection from it.<br>
<br>
I am using 9.4.0. Do you mean that I should be able to use this?<br>
<br>
proj_normalize_for_visualization(0,<br>
                                       proj_create_crs_to_crs( 0,<br>
                                                               "EPSG:4326",<br>
                                                               "EPSG:3006",<br>
                                                               0))))<br>
<br>
If that's what you mean, it seems that the convergence values are not<br>
as expected. Or do you mean something else?<br>
<br>
><br>
> On Thu, 24 Oct 2024, 14:27 Thomas Knudsen via PROJ, <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:<br>
>><br>
>> Roger,<br>
>><br>
>> The "factors" elements refer to a projection, not to a CRS<br>
>> (the CRS includes reference frame information), and not<br>
>> to a transformation (which describes a path between two<br>
>> different CRS).<br>
>><br>
>> So you should only call proj_factors on a PJ object obtained<br>
>> from a plain classic proj(ection) string, i.e:<br>
>><br>
>> p = proj_create(0, "proj=utm  zone=33  ellps=GRS80");<br>
>><br>
>><br>
>> Den tors. 24. okt. 2024 kl. 14.11 skrev Roger Oberholtzer via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>>:<br>
>>><br>
>>> 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>
>><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>
<br>
<br>
<br>
-- <br>
Roger Oberholtzer<br>
</blockquote></div>