[PROJ] general use of proj_factors

[Javier Jimenez Shaw]

About proj_create_crs_to_crs, I think you need the geographic as lon-lat
and radians (as Kristian suggested) for the input of proj_factors(). I do
not know how to get that easily.

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

> On Fri, Oct 25, 2024 at 10:59 AM Javier Jimenez Shaw <j1 at jimenezshaw.com>
> wrote:
> >
> > 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).
>
> I suspected something like that must be going on. So I will continue
> my efforts at getting the required definition without the +type=crs.
>
> My thought is to do something like:
>
> PJ *tmp = proj_create("EPSG:5678");
> PJ_PROJ_INFO info = proj_pj_info(tmp);
> PJ *used = proj_create(info.definition);
> proj_destroy(tmp);
>
> Where 'used' will be used in the proj_factors() call. It seems the
> info.definition string does not contain the +type=crs . Is there no
> way to get the definition without the call ti proj_create? Like with
> the "EPSG:5678" directly?
>
> I'm still checking if this works.
>
> Thanks all for the feedback.
>
>
>
> --
> Roger Oberholtzer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20241025/eb0518de/attachment.htm>