[PROJ] general use of proj_factors

[Roger Oberholtzer]

On Thu, Oct 24, 2024 at 2:36 PM Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:
>
> The last versions also accept a projected CRS, extracting the projection from it.

I am using 9.4.0. Do you mean that I should be able to use this?

proj_normalize_for_visualization(0,
                                       proj_create_crs_to_crs( 0,
                                                               "EPSG:4326",
                                                               "EPSG:3006",
                                                               0))))

If that's what you mean, it seems that the convergence values are not
as expected. Or do you mean something else?

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



-- 
Roger Oberholtzer