[PROJ] general use of proj_factors

[Javier Jimenez Shaw]

This is just a guess based on what I remember from the implementation.

if it has the "+type=crs", it would be understood as a CRS (makes sense).
In that case, it creates some auxiliary objects to compute the
transformation from the geographic to the projected, and call itself with
that transformation (yes, it is a recursive call).
Apparently the creation of those auxiliary objects to generate the
transformation is more expensive than the computation of the factors
themselves (it makes sense: the computation of the factors is "just" some
mathematical operations, that the CPU can do very efficiently. Creating
objects is something else).

On Fri, 25 Oct 2024 at 10:51, Roger Oberholtzer <roger.oberholtzer at gmail.com>
wrote:

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