[PROJ] general use of proj_factors

[Javier Jimenez Shaw]

The last versions also accept a projected CRS, extracting the projection
from it.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20241024/3920cd1d/attachment.htm>