Re: [PROJ] general use of proj_factors

> 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 C

Re: [PROJ] general use of proj_factors

Roger, The "factors" elements refer to a projection, not to a CRS (the CRS includes reference frame information), and not to a transformation (which describes a path between two different CRS). So you should only call proj_factors on a PJ object obtained from a plain classic proj(ection) string,

Re: [PROJ] Motion: adopt RFC8: Embedding resource files into libproj

+1 Thomas Den tors. 17. okt. 2024 kl. 13.04 skrev Even Rouault via PROJ < proj@lists.osgeo.org>: > Hi, > > Motion: adopt RFC8: Embedding resource files into libproj > > https://github.com/OSGeo/PROJ/pull/4274 > > > (GDAL parts have been moved to a GDAL s

Re: [PROJ] Geodetic to Authalic latitude conversions

I totally agree with Charles regarding using Horner for polynomial evaluation and Clenshaw for the trig series - for accuracy and speed. I implemented all the material from Charles' preprint https://arxiv.org/pdf/2212.05818 for Rust Geodesy, when the preprint appeared about 1½ years ago. And alth

Re: [PROJ] Ellipsoidal distances, with different heights

Greg Troxel said: > Or go full Pythagoras > (geodesic_distance)^2 + (h_start-h_end)^2)^1/2 That's the approach taken in the proj_lpz_dist function in the PROJ 4D API: https://github.com/OSGeo/PROJ/blob/298f7f6f967bb62fa8abf6a243dce46ae05cd474/src/4D_api.cpp#L148-L153

Re: [PROJ] PROJ 9.4.1RC1 & PROJ-data 1.18RC1

+1 Thomas lør. 1. jun. 2024 13.00 skrev Even Rouault via PROJ : > +1 Even > Le 01/06/2024 à 07:23, Kristian Evers via PROJ a écrit : > > Apart from the issue with the ._-files in the PROJ-data packages no issues > has been reported. I hereby motion that both release candidates be promoted > to fi

Re: [PROJ] Make push and pop FIFO?

Jochem, You're most welcome to submit a PR with a solution that fits your needs. Otherwise, I believe the solution to the problem you mention is to have a geometric national system, which you link to the global with a Helmert operation, then a separate step for the geometric-to-geophysical. Altern

Re: [PROJ] Make push and pop FIFO?

Hello Jochem, There's a proof(?)-of-concept of the "flip" stack-to-register-to-stack operator, you suggested over at Rust Geodesy [1],[2], with (limited) docs at [3]. You're very welcome to check it (e.g. using the "kp" coordinate processing program), and comment and/or provide test cases, to eval

Re: [PROJ] PROJ 9.4.0RC1 & PROJ-data 1.17RC1

+1 /Thomas Den tors. 29. feb. 2024 kl. 18.50 skrev Kristian Evers via PROJ < proj@lists.osgeo.org>: > PSC Members, > > Apart from the bonus files from my Mac having found their way into > PROJ-data release candidates 1-3 no problems with the release candidates > seem to have been reported. With P

Re: [PROJ] Make push and pop FIFO?

> I believe the main objection to named variable, was: > what happens when one nests / copy-paste part of > pipelines in a more complex pipelines. @Even, As I have already said earlier in this thread, this is not a problem with nested pipelines (as they execute in their own context). But it migh

Re: [PROJ] Make push and pop FIFO?

Thanks Even! This is really awesome. I have taken a brief look at the code and docs. At first read, some of the docs confused me a bit - but I will take a closer look Thursday (I'm fully booked right now) ___ PROJ mailing list PROJ@lists.osgeo.org https:/

Re: [PROJ] Make push and pop FIFO?

Javier said: > I was thinking about that. How to ensure that an inner > step will not use the same register name? That's less of a problem than it seems: An inner step would come from an inner pipeline instantiated through an init=foo:bar step, so in that case, a *separate* pipeline instantiation

Re: [PROJ] Make push and pop FIFO?

> stack swap, flip: sorry but my own imperfect brain of a > programmer not having coded in Forth, I will have a very > hard time to remember what they do exactly without > referring to the doc :-) But I believe you have programmed in assembly, which is exactly the same. "swap" swaps the top-of-st

Re: [PROJ] Make push and pop FIFO?

Jochem, Even: The main problem with PROJ's current push/pop functionality is that the four-stack implementation makes it impossible to push one dimension of a coordinate-tuple and pop it into another, without an elaborate axisswap dance at both ends of the push/pop-pair. This is a consequence of

Re: [PROJ] Bump CMake to 3.14+

Definitely +1 /Thomas ___ PROJ mailing list PROJ@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/proj

Re: [PROJ] Bump CMake to 3.14+

I also find it hard to see any reasonable arguments against 3.16 /Thomas Den man. 8. jan. 2024 kl. 18.43 skrev Even Rouault via PROJ < proj@lists.osgeo.org>: > I'm also supporting of bumping to CMake 3.16+. You'll have at least to > retire the .github/workflows/linux_gcc_5_4.yml workflow, which

Re: [PROJ] Make push and pop FIFO?

Contrary to you, Even, I find the push/pop duality clear, non-confusing, and totally in line with the overall design of PROJ operators. I would, however, for even more consistency, have preferred a single stack design Why do I find it so clear? Four reasons: 1. The opposite of "proj=utm" is "proj

Re: [PROJ] Make push and pop FIFO?

> > Greg Troxel said: > > We are really re-inventing the traditional HP RPN, and > > that's ok, but it's better to re-implement it as > > consistently as possible. > > Actually Chuck Moore implemented Forth already in 1968, > four years before HP-35, the first HP RPN calculator, > was introduced. S

Re: [PROJ] Make push and pop FIFO?

Hi Jochem, So if I'm not entirely mistaken, you'll need something like the Forth "swap" operator, or the PostScript "exch" operator to allow something like this: ### The inverse part (read from bottom up, and read pop as push, push as pop) ### step omit_fwd proj=push v_3 # restore

Re: [PROJ] Make push and pop FIFO?

If your input data does not need time stamps, you may be able to work around this using +omit_fwd/+omit_inv selectors and a set of axisswap order=1,2,4,3 steps? Den tors. 14. dec. 2023 kl. 14.13 skrev Lesparre, Jochem via PROJ < proj@lists.osgeo.org>: > Hi list members, > > > > The PROJ operation

Re: [PROJ] PROJ 9.3.1RC1 & PROJ-data 1.16RC1

+1 /Thomas fre. 1. dec. 2023 06.53 skrev Kristian Evers via PROJ : > PSC members, > > No issues have been reported with the two release candidates so I motion > that they > are promoted to final releases. > > I’ll start with my +1. > > /Kristian > > > On 26 Nov 2023, at 20.01, Even Rouault > wro

Re: [PROJ] Motion: add Javier Jiménez Shaw to PROJ PSC

+1 Thomas Den lør. 16. sep. 2023 kl. 13.25 skrev Even Rouault via PROJ < proj@lists.osgeo.org>: > Hi, > > I would like to nominate Javier Jiménez Shaw for PROJ PSC membership. > Javier has been involved with PROJ for quite a time now, and is a > passionate about CRS. He has authored several commi