[PROJ] general use of proj_factors

[Thomas Knudsen]

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