[PROJ] general use of proj_factors

[Roger Oberholtzer]

On Thu, Oct 24, 2024 at 5:42 PM Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:
>
> https://proj.org/en/9.5/development/reference/functions.html#c.proj_factors
> You just provide the projected CRS, just created from the EPSG code. It converts it internally into the projection over its geographic.

If I use something defined with proj_create_crs_to_crs I get incorrect
values for the meridian convergence. If I provide an EPSG code to
proj_create and use that, I get the correct values, but it takes an
extremely long time for each calculation. As I wrote, projections that
should take 15 minutes take 15 hours. The thing that seems to work
best is proj_create with a proj string that does not contain
+type=crs. I am wondering if this is all expected behavior.


>
> On Thu, 24 Oct 2024 at 15:19, Roger Oberholtzer <roger.oberholtzer at gmail.com> wrote:
>>
>> 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



-- 
Roger Oberholtzer