[PROJ] general use of proj_factors
Roger Oberholtzer
roger.oberholtzer at gmail.com
Fri Oct 25 01:51:17 PDT 2024
On Fri, Oct 25, 2024 at 10:31 AM Thomas Knudsen
<knudsen.thomas at gmail.com> wrote:
>
> > If I use something defined with proj_create_crs_to_crs I get incorrect
> values for the meridian convergence
>
> Which is as expected: proj_create_crs_to_crs returns a transformation
> BETWEEN two CRS. The geometrical factors are meaningfully defined
> for projections only. A transformation between two CRS is not in general
> a projection.
>
> You may get some numbers out of calling proj_factors with a transformation
> as an argument, but you should not expect any kind of meaningful result.
>
> Also, you may get numbers out of a PJ generated from a CRS (EPSG:nnnn),
> by ignoring the reference frame information implied, in which case an
> eventual projection remains. But if the CRS is, say, geographical or
> geocentric cartesian, the factors are meaningless.
>
> **It's apples and pears**. Don't expect meaningful proj_factors from anything
> other than a traditional projection specification.
I'm fully with you. And making a general implementation of this is
what I am trying to accomplish. The calculation time of proj_factors
when the spec includes +type=crs is the current issue. When I define
things with, say:
proj_create("EPSG:5678")
The proj_factors call takes over 60x longer (exact timing difference
to be reported soon) than for:
proj_create("+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000
+y_0=0 +ellps=bessel +towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7
+units=m +no_defs")
The second is the proj string from projinfo for EPSG:5678 - minus the
+type=crs. I purposely left all the perhaps not needed items to
demonstrate that it is the +type=crs that is the time culprit. I
should add that in either case, the actual meridian convergence value
is the same. But taking 15 hours instead of 15 minutes to make a point
cloud is prohibitive. Hence my investigation.
Your point on where the meridian convergence is going to be a
meaningless value are understood. How to restrict this to valid
projections is next up on my todo list.
--
Roger Oberholtzer
More information about the PROJ
mailing list