[PROJ] general use of proj_factors
Roger Oberholtzer
roger.oberholtzer at gmail.com
Fri Oct 25 05:47:43 PDT 2024
On Fri, Oct 25, 2024 at 2:39 PM Even Rouault <even.rouault at spatialys.com> wrote:
>
>
> Le 25/10/2024 à 14:24, Roger Oberholtzer a écrit :
>
> On Fri, Oct 25, 2024 at 1:14 PM Even Rouault <even.rouault at spatialys.com> wrote:
>
> 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.
>
> Should be fixed per https://github.com/OSGeo/PROJ/pull/4289
>
> Fantastic! I can't wait to try it! I'm running 9.4.x. When do you
> guess it might be in a release?
>
> I've queued it for 9.6.0 March next year. Could potentially be backported to 9.5 but I'd be a bit nervous to do that in a bugfix release because it might break people (ab)using proj_factors() by calling it from multiple threads on the same PJ* object.
For important projections (i.e., those in areas where we perform
measurements) we have a thin wrapper function around proj where we
can do any needed fiddling. In these I have added the needed calls to
set up proj_factors() to operate in a speedy fashion. Our goal is to
minimize, if not eliminate these wrapper functions in favor of using
EPSG codes directly. So, generally speaking, we are good to go (now
that I see the +type_crs effect). But perhaps in March we can realize
our goal of not needing these wrapper functions.
I guess this will be available in a beta release? If so, I can check
that to see how the addition effects things.
Once again, thanks!
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
--
Roger Oberholtzer
More information about the PROJ
mailing list