On Fri, Oct 25, 2024 at 2:39 PM Even Rouault <even.roua...@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.roua...@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 _______________________________________________ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj
