From j1 at jimenezshaw.com  Mon Feb  9 05:06:10 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Mon, 9 Feb 2026 14:06:10 +0100
Subject: [PROJ] Unitconvert after topocentric conversion
Message-ID: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>

Hi

I would like to compute the difference in a topocentric system (ENU) from
points in geocentric coordinates... with the output in millimetres.

echo 4000000.0000 300000.0000  5000001.0000 | cct +pipeline +step
+proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
+step +proj=unitconvert +xy_in=m +xy_out=mm +z_in=m +z_out=mm
        0.0000         0.6232        0.7820           inf

But that is exactly the same output if I do not do the unit conversion.

echo 4000000.0000 300000.0000  5000001.0000 | cct +pipeline +step
+proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
        0.0000         0.6232        0.7820           inf

Am I doing something wrong?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260209/9082a1c6/attachment.htm>

From kristian at evers.dev  Mon Feb  9 05:49:07 2026
From: kristian at evers.dev (Kristian Evers)
Date: Mon, 09 Feb 2026 13:49:07 +0000
Subject: [PROJ] Unitconvert after topocentric conversion
In-Reply-To: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
References: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
Message-ID: <zookxpkz8gAc3UMxAwhb-itqufoU4tbTeZUxgLWo--gJJrTt1lht6oyebHx3Bd94JmdgR46QveyXtx9_JlcJuFA3qSsVCEbxK-skaXS3cj4=@evers.dev>

Looks like a bug to me.

/Kristian

On Monday, February 9th, 2026 at 14:12, Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> wrote:

> Hi
>
> I would like to compute the difference in a topocentric system (ENU) from points in geocentric coordinates... with the output in millimetres.
>
> echo 4000000.0000 300000.0000 5000001.0000 | cct +pipeline +step +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000 +step +proj=unitconvert +xy_in=m +xy_out=mm +z_in=m +z_out=mm
> 0.0000 0.6232 0.7820 inf
>
> But that is exactly the same output if I do not do the unit conversion.
>
> echo 4000000.0000 300000.0000 5000001.0000 | cct +pipeline +step +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
> 0.0000 0.6232 0.7820 inf
>
> Am I doing something wrong?
>
> Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260209/404bbb0d/attachment-0001.htm>

From even.rouault at spatialys.com  Mon Feb  9 09:54:10 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 9 Feb 2026 18:54:10 +0100
Subject: [PROJ] Unitconvert after topocentric conversion
In-Reply-To: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
References: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
Message-ID: <ea51647f-406a-49c0-9664-89e2f3253e8d@spatialys.com>

Hi,

just a syntax issue : replace +pipeline with +proj=pipeline

Even

Le 09/02/2026 ? 14:06, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> I would like to compute the difference in a topocentric system (ENU) 
> from points in geocentric coordinates... with the output in millimetres.
>
> echo 4000000.0000 300000.0000 ?5000001.0000 | cct +pipeline +step 
> +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000 
> +step +proj=unitconvert +xy_in=m +xy_out=mm +z_in=m +z_out=mm
> ? ? ? ? 0.0000 0.6232 ? ? ? ?0.7820 ? ? ? ? ? inf
>
> But that is exactly the same output if I do not do the unit conversion.
>
> echo 4000000.0000 300000.0000 ?5000001.0000 | cct +pipeline +step 
> +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
> ? ? ? ? 0.0000 0.6232 ? ? ? ?0.7820 ? ? ? ? ? inf
>
> Am I doing something wrong?
>
> Thanks.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260209/5f3862c4/attachment.htm>

From j1 at jimenezshaw.com  Mon Feb  9 10:00:53 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Mon, 9 Feb 2026 19:00:53 +0100
Subject: [PROJ] Unitconvert after topocentric conversion
In-Reply-To: <ea51647f-406a-49c0-9664-89e2f3253e8d@spatialys.com>
References: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
 <ea51647f-406a-49c0-9664-89e2f3253e8d@spatialys.com>
Message-ID: <CADRrdKsbFYRDxLrzcN=hAd=dq9t9siGOPExnL4ng1qZ7Zu7oUw@mail.gmail.com>

Thanks Even!

So the syntax was clearly wrong. Should it fail, instead of run just the
first step?

On Mon, 9 Feb 2026 at 18:54, Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi,
>
> just a syntax issue : replace +pipeline with +proj=pipeline
>
> Even
> Le 09/02/2026 ? 14:06, Javier Jimenez Shaw via PROJ a ?crit :
>
> Hi
>
> I would like to compute the difference in a topocentric system (ENU) from
> points in geocentric coordinates... with the output in millimetres.
>
> echo 4000000.0000 300000.0000  5000001.0000 | cct +pipeline +step
> +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
> +step +proj=unitconvert +xy_in=m +xy_out=mm +z_in=m +z_out=mm
>         0.0000         0.6232        0.7820           inf
>
> But that is exactly the same output if I do not do the unit conversion.
>
> echo 4000000.0000 300000.0000  5000001.0000 | cct +pipeline +step
> +proj=topocentric +X_0=4000000.0000 +Y_0=300000.0000 +Z_0=5000000.0000
>         0.0000         0.6232        0.7820           inf
>
> Am I doing something wrong?
>
> Thanks.
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260209/2213c787/attachment.htm>

From even.rouault at spatialys.com  Mon Feb  9 10:04:16 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 9 Feb 2026 19:04:16 +0100
Subject: [PROJ] Unitconvert after topocentric conversion
In-Reply-To: <CADRrdKsbFYRDxLrzcN=hAd=dq9t9siGOPExnL4ng1qZ7Zu7oUw@mail.gmail.com>
References: <CADRrdKsf_qXcLkxmVgxJHfU0pMYyo2ON1rx7mF-f703yO2krFw@mail.gmail.com>
 <ea51647f-406a-49c0-9664-89e2f3253e8d@spatialys.com>
 <CADRrdKsbFYRDxLrzcN=hAd=dq9t9siGOPExnL4ng1qZ7Zu7oUw@mail.gmail.com>
Message-ID: <7e6aa7d1-9242-4c51-b6d0-571ca6beb607@spatialys.com>


Le 09/02/2026 ? 19:00, Javier Jimenez Shaw a ?crit?:
> Thanks Even!
>
> So the syntax was clearly wrong. Should it fail, instead of run just 
> the first step?

In that context, yes it would be clearly desirable to fail.? But how to 
distinguish such case where other cases where people have introduced 
stuff like +title=bla that was intended to be silently ignored ?

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From j1 at jimenezshaw.com  Sat Feb 21 10:31:15 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Sat, 21 Feb 2026 19:31:15 +0100
Subject: [PROJ] Wrong transformation in NL?
Message-ID: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>

Hi

Just testing something else, I tried this transformation to go test that
the grids are properly used.
In master this seems to be wrong

echo 52 5 0 | PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/cs2cs EPSG:4326+3855
EPSG:7415
128410.09 445806.51 -43.41

./bin/cs2cs
Rel. 9.8.0, March 2nd, 2026

While in the native cs2cs in Ubuntu 24.04 makes more sense. Just 20 cm
difference between EGM2008 and NAP height.

echo 52 5 0 | PROJ_NETWORK=ON cs2cs EPSG:4326+3855 EPSG:7415
128410.10 445806.50 0.20

cs2cs
Rel. 9.4.0, March 1st, 2024

The first pipeline of the projinfo are ... the same? I don't understand

PROJ_NETWORK=ON projinfo -s EPSG:4326+3855 -t EPSG:7415 -o proj --bbox
5,52,5.1,52.1
Candidate operations found: 2
-------------------------------------
Operation No. 1:

unknown id, Inverse of WGS 84 to EGM2008 height (1) + Inverse of ETRS89 to
WGS 84 (1) + ETRS89 to NAP height (2) + Inverse of Amersfoort to ETRS89 (9)
+ RD New, 2.002 m, Netherlands - onshore, including Waddenzee, Dutch Wadden
Islands and 12-mile offshore coastal zone.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
  +step +inv +proj=vgridshift +grids=nl_nsgi_nlgeo2018.tif +multiplier=1
  +step +inv +proj=hgridshift +grids=nl_nsgi_rdtrans2018.tif
  +step +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889
+k=0.9999079
        +x_0=155000 +y_0=463000 +ellps=bessel

-------------------------------------
Operation No. 2:


PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/projinfo -s EPSG:4326+3855 -t
EPSG:7415 -o proj --bbox 5,52,5.1,52.1
Candidate operations found: 6
-------------------------------------
Operation No. 1:

unknown id, Inverse of WGS 84 to EGM2008 height (1) + Inverse of ETRS89-NLD
[AGRS2010] to WGS 84 (1) + ETRS89-NLD [AGRS2010] to NAP height (2) +
Inverse of Amersfoort to ETRS89-NLD [AGRS2010] (9) + RD New, 1.123 m,
Netherlands - onshore and offshore.

PROJ string:
+proj=pipeline
  +step +proj=axisswap +order=2,1
  +step +proj=unitconvert +xy_in=deg +xy_out=rad
  +step +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
  +step +inv +proj=vgridshift +grids=nl_nsgi_nlgeo2018.tif +multiplier=1
  +step +inv +proj=hgridshift +grids=nl_nsgi_rdtrans2018.tif
  +step +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889
+k=0.9999079
        +x_0=155000 +y_0=463000 +ellps=bessel

-------------------------------------
Operation No. 2:

If my tests are correct, and I had to guess, I would say it is a
consequence of the new ETRS89 ensemble.

Cheers,
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260221/3d91fd0e/attachment.htm>

From even.rouault at spatialys.com  Sat Feb 21 12:11:35 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sat, 21 Feb 2026 21:11:35 +0100
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
Message-ID: <d31c2c83-312e-448a-982e-3237c8d59822@spatialys.com>

Analysis and fix in https://github.com/OSGeo/PROJ/pull/4676

Le 21/02/2026 ? 19:31, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> Just testing something else, I tried this transformation to go test 
> that the grids are properly used.
> In master this seems to be wrong
>
> echo 52 5 0 | PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/cs2cs 
> EPSG:4326+3855 EPSG:7415
> 128410.09 445806.51 -43.41
>
> ./bin/cs2cs
> Rel. 9.8.0, March 2nd, 2026
>
> While in the native cs2cs in Ubuntu 24.04 makes more sense. Just 20 cm 
> difference between EGM2008 and NAP height.
>
> echo 52 5 0 | PROJ_NETWORK=ON cs2cs EPSG:4326+3855 EPSG:7415
> 128410.10 445806.50 0.20
>
> cs2cs
> Rel. 9.4.0, March 1st, 2024
>
> The first pipeline of the projinfo are ... the same? I don't understand
>
> PROJ_NETWORK=ON projinfo -s EPSG:4326+3855 -t EPSG:7415 -o proj --bbox 
> 5,52,5.1,52.1
> Candidate operations found: 2
> -------------------------------------
> Operation No. 1:
>
> unknown id, Inverse of WGS 84 to EGM2008 height (1) + Inverse of 
> ETRS89 to WGS 84 (1) + ETRS89 to NAP height (2) + Inverse of 
> Amersfoort to ETRS89 (9) + RD New, 2.002 m, Netherlands - onshore, 
> including Waddenzee, Dutch Wadden Islands and 12-mile offshore coastal 
> zone.
>
> PROJ string:
> +proj=pipeline
> ? +step +proj=axisswap +order=2,1
> ? +step +proj=unitconvert +xy_in=deg +xy_out=rad
> ? +step +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
> ? +step +inv +proj=vgridshift +grids=nl_nsgi_nlgeo2018.tif +multiplier=1
> ? +step +inv +proj=hgridshift +grids=nl_nsgi_rdtrans2018.tif
> ? +step +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889 
> +k=0.9999079
> ? ? ? ? +x_0=155000 +y_0=463000 +ellps=bessel
>
> -------------------------------------
> Operation No. 2:
>
>
> PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/projinfo -s EPSG:4326+3855 -t 
> EPSG:7415 -o proj --bbox 5,52,5.1,52.1
> Candidate operations found: 6
> -------------------------------------
> Operation No. 1:
>
> unknown id, Inverse of WGS 84 to EGM2008 height (1) + Inverse of 
> ETRS89-NLD [AGRS2010] to WGS 84 (1) + ETRS89-NLD [AGRS2010] to NAP 
> height (2) + Inverse of Amersfoort to ETRS89-NLD [AGRS2010] (9) + RD 
> New, 1.123 m, Netherlands - onshore and offshore.
>
> PROJ string:
> +proj=pipeline
> ? +step +proj=axisswap +order=2,1
> ? +step +proj=unitconvert +xy_in=deg +xy_out=rad
> ? +step +proj=vgridshift +grids=us_nga_egm08_25.tif +multiplier=1
> ? +step +inv +proj=vgridshift +grids=nl_nsgi_nlgeo2018.tif +multiplier=1
> ? +step +inv +proj=hgridshift +grids=nl_nsgi_rdtrans2018.tif
> ? +step +proj=sterea +lat_0=52.1561605555556 +lon_0=5.38763888888889 
> +k=0.9999079
> ? ? ? ? +x_0=155000 +y_0=463000 +ellps=bessel
>
> -------------------------------------
> Operation No. 2:
>
> If my tests are correct, and I had to guess, I would say it is a 
> consequence of the new ETRS89 ensemble.
>
> Cheers,
> Javier.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260221/5437fa59/attachment-0001.htm>

From gdt at lexort.com  Sat Feb 21 17:22:30 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 21 Feb 2026 20:22:30 -0500
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 (Javier Jimenez Shaw via PROJ's message of "Sat, 21 Feb 2026 19:31:15
 +0100")
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
Message-ID: <rmifr6t373d.fsf@s1.lexort.com>

Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:

> Just testing something else, I tried this transformation to go test that
> the grids are properly used.
> In master this seems to be wrong
>
> echo 52 5 0 | PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/cs2cs EPSG:4326+3855
> EPSG:7415
> 128410.09 445806.51 -43.41
>
> ./bin/cs2cs
> Rel. 9.8.0, March 2nd, 2026
>
> While in the native cs2cs in Ubuntu 24.04 makes more sense. Just 20 cm
> difference between EGM2008 and NAP height.
>
> echo 52 5 0 | PROJ_NETWORK=ON cs2cs EPSG:4326+3855 EPSG:7415
> 128410.10 445806.50 0.20
>
> cs2cs
> Rel. 9.4.0, March 1st, 2024

Separately from what's being viewed as a bug, etc. WGS84 is an ensemble
with 2m error just from the ensemble.  But I would then expect any wrong
answers people are complaining about to be within 2m or so.

Am I reading this right that 0 m in EGM2008 is 20 cm in NAP?  (I get it
that this is super close and we expect close since they are both trying
to match mean sea level, with the caveat that mean sea level is a
difficult concept, with EGM2008 tied to some global MSL and NAP to some
measured sea level over some period at one(?) tide gauge.)

What I'm boggled by is -43.41 m.  That feels like a geoid height, not a
difference it orthometric datum reference surface.  Which suggests that
something is more seriously wrong.

> If my tests are correct, and I had to guess, I would say it is a
> consequence of the new ETRS89 ensemble.

Do you mean "ETRS89 recently got a new member ETRF2020"?  Without really
understanding, I would expect coordinate differences between ETRF2000
and ETRF2020 to be on the order of one to a few cm, and that this is not
able to explain a 1m delta, let along 43m.

(Also, I think this discussion is all about NAP and not about EVRF at
all.)

From j1 at jimenezshaw.com  Sat Feb 21 17:35:30 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Sun, 22 Feb 2026 02:35:30 +0100
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <rmifr6t373d.fsf@s1.lexort.com>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
Message-ID: <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>

Even anyway answered with a bugfix.

ETRS89 now has more than 40 new members, from many European countries. The
change is a free days old in EPSG.
Yes, the 40m difference is the geoid height in Europe.

On Sun, 22 Feb 2026, 02:22 Greg Troxel via PROJ, <proj at lists.osgeo.org>
wrote:

> Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:
>
> > Just testing something else, I tried this transformation to go test that
> > the grids are properly used.
> > In master this seems to be wrong
> >
> > echo 52 5 0 | PROJ_DATA=data/ PROJ_NETWORK=ON ./bin/cs2cs EPSG:4326+3855
> > EPSG:7415
> > 128410.09 445806.51 -43.41
> >
> > ./bin/cs2cs
> > Rel. 9.8.0, March 2nd, 2026
> >
> > While in the native cs2cs in Ubuntu 24.04 makes more sense. Just 20 cm
> > difference between EGM2008 and NAP height.
> >
> > echo 52 5 0 | PROJ_NETWORK=ON cs2cs EPSG:4326+3855 EPSG:7415
> > 128410.10 445806.50 0.20
> >
> > cs2cs
> > Rel. 9.4.0, March 1st, 2024
>
> Separately from what's being viewed as a bug, etc. WGS84 is an ensemble
> with 2m error just from the ensemble.  But I would then expect any wrong
> answers people are complaining about to be within 2m or so.
>
> Am I reading this right that 0 m in EGM2008 is 20 cm in NAP?  (I get it
> that this is super close and we expect close since they are both trying
> to match mean sea level, with the caveat that mean sea level is a
> difficult concept, with EGM2008 tied to some global MSL and NAP to some
> measured sea level over some period at one(?) tide gauge.)
>
> What I'm boggled by is -43.41 m.  That feels like a geoid height, not a
> difference it orthometric datum reference surface.  Which suggests that
> something is more seriously wrong.
>
> > If my tests are correct, and I had to guess, I would say it is a
> > consequence of the new ETRS89 ensemble.
>
> Do you mean "ETRS89 recently got a new member ETRF2020"?  Without really
> understanding, I would expect coordinate differences between ETRF2000
> and ETRF2020 to be on the order of one to a few cm, and that this is not
> able to explain a 1m delta, let along 43m.
>
> (Also, I think this discussion is all about NAP and not about EVRF at
> all.)
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260222/44cfb192/attachment.htm>

From gdt at lexort.com  Sat Feb 21 17:42:40 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 21 Feb 2026 20:42:40 -0500
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
 (Javier Jimenez Shaw's message of "Sun, 22 Feb 2026 02:35:30 +0100")
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
 <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
Message-ID: <rmi8qcl365r.fsf@s1.lexort.com>

Javier Jimenez Shaw <j1 at jimenezshaw.com> writes:

> Even anyway answered with a bugfix.

Thanks - I saw that, but I didn't understand.

> ETRS89 now has more than 40 new members, from many European countries. The
> change is a free days old in EPSG.

I am guessing these are ETRFxx(country), and that this is mor or less
like NAD83(2011) vs NAD83(CSRSv8), an intent to produce ETRS89 that is
valid in that country, and then it becomes a standard of its own because
people repeatability of that to a greater acccuracy than how well that
country-specific ETRF realizes ETRS89.    But still - are there ensemble
members that are 1m different?

> Yes, the 40m difference is the geoid height in Europe.

So was the bug confusing orthometric and ellipsoidal?  It seems it was
about preference for transforms that were all sort of ok.

From Jochem.Lesparre at kadaster.nl  Sun Feb 22 05:15:29 2026
From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem)
Date: Sun, 22 Feb 2026 13:15:29 +0000
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <rmi8qcl365r.fsf@s1.lexort.com>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
 <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
 <rmi8qcl365r.fsf@s1.lexort.com>
Message-ID: <DU2P192MB2235E2289ED1F870C41C4D1EEF76A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>

Hi,



[ER]: PROJ synthetized a new operation (operation 3) that has the same accuracy than the "correct" (operation 1), and a smaller area of use, thus it was selected.



Thanks for this fix.



[GT]: So was the bug confusing orthometric and ellipsoidal?



No, PROJ used an inappropriate geoid. The 2D Amersfoort datum of the 2D target CRS RD has an ellipsoidal height within 1 m of MSL in the Netherlands. PROJ nevertheless thought it was a good idea to take the geoid for the vertical target CRS NAP that is to be used on 3D ETRS89 and apply it on the Amersfoort ellipsoidal height.



[GT]: Am I reading this right that 0 m in EGM2008 is 20 cm in NAP?  (I get it that this is super close and we expect close since they are both trying to match mean sea level, with the caveat that mean sea level is a difficult concept, with EGM2008 tied to some global MSL and NAP to some measured sea level over some period at one(?) tide gauge.)



Yes, NAP and EGM2008 are within 0,4 m. NAP is mean summer hightide in Amsterdam in 1683-1684, way before its open connection to the sea was dammed. Nowadays, MSL in the North Sea is close to NAP.



GT: It seems it was about preference for transforms that were all sort of ok.



Yes, the transformations are more or less correct. I did however start a discussion with EPSG on the Amersfoort to WGS 84 transformation https://epsg.org/transformation_4833/Amersfoort-to-WGS-84-4.html this month. At least, the accuracy should be corrected from 1 m to 1.25 m and the extent enlarged to Netherlands onshore + offshore. Other options are to remove or to supersede this transformation by a copy of https://epsg.org/transformation_9282/Amersfoort-to-ETRS89-NLD-AGRS2010-9.html or to create a concatenated operation or pipeline to enforce the transformation route Amersfoort - ETRF2000 - WGS 84 (where the second step is a null transformation).



Regards, Jochem






Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].

Disclaimer:
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products and services
[https://www.kadaster.com/general-terms-and-conditions].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260222/2009b499/attachment-0001.htm>

From j1 at jimenezshaw.com  Sun Feb 22 06:28:08 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Sun, 22 Feb 2026 15:28:08 +0100
Subject: [PROJ] Creating a dynamic system
Message-ID: <CADRrdKuA__dxLfGF4XDuFE8bPNrWCMF6tNKRogQ7e+UBOH7LsA@mail.gmail.com>

Hi

the C function proj_coordinate_metadata_create can
https://proj.org/en/stable/development/reference/functions.html#c.proj_coordinate_metadata_create
allows to create a dynamic system with an epoch.

In case the crs is not dynamic, it fails and emits an error.
However I do not see how to check if a system is dynamic, to call it only
if really needed.

Is there such a function in the C API?

Cheers
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260222/7b23e92f/attachment.htm>

From even.rouault at spatialys.com  Sun Feb 22 09:32:07 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 22 Feb 2026 18:32:07 +0100
Subject: [PROJ] Creating a dynamic system
In-Reply-To: <CADRrdKuA__dxLfGF4XDuFE8bPNrWCMF6tNKRogQ7e+UBOH7LsA@mail.gmail.com>
References: <CADRrdKuA__dxLfGF4XDuFE8bPNrWCMF6tNKRogQ7e+UBOH7LsA@mail.gmail.com>
Message-ID: <c32d45de-0a10-4eca-ba7b-717aa10259a9@spatialys.com>


Le 22/02/2026 ? 15:28, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> the C function?proj_coordinate_metadata_create can
> https://proj.org/en/stable/development/reference/functions.html#c.proj_coordinate_metadata_create
> allows to create a dynamic system with an epoch.
>
> In case the crs is not dynamic, it fails and emits an error.
> However I do not see how to check if a system is dynamic, to call it 
> only if really needed.
>
> Is there such a function in the C API?

checking proj_get_type() == PJ_TYPE_DYNAMIC_GEODETIC_REFERENCE_FRAME on 
the result of proj_crs_get_datum()

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From even.rouault at spatialys.com  Sun Feb 22 10:12:21 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 22 Feb 2026 19:12:21 +0100
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <DU2P192MB2235E2289ED1F870C41C4D1EEF76A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
 <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
 <rmi8qcl365r.fsf@s1.lexort.com>
 <DU2P192MB2235E2289ED1F870C41C4D1EEF76A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>
Message-ID: <9205ee6a-7359-48e1-aaf3-2718dd1fa702@spatialys.com>

> [GT]: So was the bug confusing orthometric and ellipsoidal?
>
> No, PROJ used an inappropriate geoid. The 2D Amersfoort datum of the 
> 2D target CRS RD has an ellipsoidal height within 1 m of MSL in the 
> Netherlands. PROJ nevertheless thought it was a good idea to take the 
> geoid for the vertical target CRS NAP that is to be used on 3D ETRS89 
> and apply it on the Amersfoort ellipsoidal height.
>
A bit more subtle than that. It did:

- WGS 84 + EGM 2008 -> WGS 84 3D geographic using EGM2008 height: OK

- use of "|Amersfoort to WGS 84 (4)" Helmert transformation in reverse 
direction, promoting the Amersfoort CRS to a 3D geographic one and do 
the Helmert transformation in 3D. That's the part that was questionnable 
(yeah, wrong) in this context since that Helmert transformatioon? is 
likely only intended for 2D. Unfortunately the EPSG database doesn't 
distinguish cases where this is valid and those where it is not. The 
only hint is that if there's no official record for a 3D geographic CRS, 
doing the Helmert transformation in 3D is likely to not be correct|

|- apply the "Amersfoort to ETRS89-NLD [AGRS2010]" transformation using 
the 2D grid|

|- apply the "||ETRS89-NLD [AGRS2010] to NAP height (2)" transformation 
using the geoid grid|

|- apply the ||"Amersfoort to ETRS89-NLD [AGRS2010]" in the reverse 
direction, to finally get Amersfoort + NAP height coordinates|


-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260222/6d8c32fd/attachment.htm>

From even.rouault at spatialys.com  Sun Feb 22 11:26:12 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 22 Feb 2026 20:26:12 +0100
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <9205ee6a-7359-48e1-aaf3-2718dd1fa702@spatialys.com>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
 <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
 <rmi8qcl365r.fsf@s1.lexort.com>
 <DU2P192MB2235E2289ED1F870C41C4D1EEF76A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>
 <9205ee6a-7359-48e1-aaf3-2718dd1fa702@spatialys.com>
Message-ID: <5cf195c3-1085-44a0-a370-480f7f37411b@spatialys.com>

Actually, re-reading my below pipeline, the issue is probably not that 
much the use of? the "Amersfoort to WGS 84 (4)" Helmert transformation 
in 3D, but? the step afterwards where we go from Amersfoort ellipsoidal 
height to ETRS 89 ellipsoidal height, using a 2D grid based operation 
(what Jochem underlined actually). I've fine tuned the compound CRS <--> 
geog3D CRS in https://github.com/OSGeo/PROJ/pull/4677 to avoid the use 
of such operations

I'm still not sure if Amersfoort ellipsoidal heights make sense, but 
with the above fix they can now be used at least as a computation 
intermediate without getting too crazy results:

$ echo 52 5 0 |? PROJ_NETWORK=ON bin/cs2cs -d 4 --3d EPSG:4326+3855 
Amersfoort | PROJ_NETWORK=ON bin/cs2cs --3d -d 4 Amersfoort "Amersfoort 
+ NAP height"
52.0010? ? 5.0004 0.1953

$ echo 52 5 0 |? PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4326+3855 
"Amersfoort + NAP height"
52.0010? ? 5.0004 0.2000

Even


Le 22/02/2026 ? 19:12, Even Rouault via PROJ a ?crit?:
>>
>> [GT]: So was the bug confusing orthometric and ellipsoidal?
>>
>> No, PROJ used an inappropriate geoid. The 2D Amersfoort datum of the 
>> 2D target CRS RD has an ellipsoidal height within 1 m of MSL in the 
>> Netherlands. PROJ nevertheless thought it was a good idea to take the 
>> geoid for the vertical target CRS NAP that is to be used on 3D ETRS89 
>> and apply it on the Amersfoort ellipsoidal height.
>>
> A bit more subtle than that. It did:
>
> - WGS 84 + EGM 2008 -> WGS 84 3D geographic using EGM2008 height: OK
>
> - use of "|Amersfoort to WGS 84 (4)" Helmert transformation in reverse 
> direction, promoting the Amersfoort CRS to a 3D geographic one and do 
> the Helmert transformation in 3D. That's the part that was 
> questionnable (yeah, wrong) in this context since that Helmert 
> transformatioon? is likely only intended for 2D. Unfortunately the 
> EPSG database doesn't distinguish cases where this is valid and those 
> where it is not. The only hint is that if there's no official record 
> for a 3D geographic CRS, doing the Helmert transformation in 3D is 
> likely to not be correct|
>
> |- apply the "Amersfoort to ETRS89-NLD [AGRS2010]" transformation 
> using the 2D grid|
>
> |- apply the "||ETRS89-NLD [AGRS2010] to NAP height (2)" 
> transformation using the geoid grid|
>
> |- apply the ||"Amersfoort to ETRS89-NLD [AGRS2010]" in the reverse 
> direction, to finally get Amersfoort + NAP height coordinates|
>
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260222/6a52c9c6/attachment.htm>

From Jochem.Lesparre at kadaster.nl  Mon Feb 23 01:11:39 2026
From: Jochem.Lesparre at kadaster.nl (Lesparre, Jochem)
Date: Mon, 23 Feb 2026 09:11:39 +0000
Subject: [PROJ] Wrong transformation in NL?
In-Reply-To: <5cf195c3-1085-44a0-a370-480f7f37411b@spatialys.com>
References: <CADRrdKu=yqnYuitxesyz7w9+ptqTyUh=1pK3=J7sAQ7j2qSVfQ@mail.gmail.com>
 <rmifr6t373d.fsf@s1.lexort.com>
 <CADRrdKvWsoSyR+z-Xny0HeyTRNQu2ztuYshyWv61Nu1Os_GcKQ@mail.gmail.com>
 <rmi8qcl365r.fsf@s1.lexort.com>
 <DU2P192MB2235E2289ED1F870C41C4D1EEF76A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>
 <9205ee6a-7359-48e1-aaf3-2718dd1fa702@spatialys.com>
 <5cf195c3-1085-44a0-a370-480f7f37411b@spatialys.com>
Message-ID: <DU2P192MB223537374176CB47A8FCF304EF77A@DU2P192MB2235.EURP192.PROD.OUTLOOK.COM>

Hi Even,

Amersfoort ellipsoidal heights were used in the past and could still be used under certain conditions. The transformation via 3D Amersfoort (your 1st example) taken here is needlessly complex (using the horizontal grid for the interpolation CRS of the geoid, but not for the horizontal coordinates), but it is correct within the accuracy. In the area of use, the maximum differences with the transformation via ETRS89-NLD [AGRS2010] recommended by the national authorities (your 2nd example) are 0.25 m horizontally and a few centimetres vertically.

Nevertheless, I'm still going to ask EPSG for changes that will favour or force transformation via ETRS89-NLD [AGRS2010] instead of 3D Amersfoort.

Regards, Jochem


1st example
$ echo 52 5 0 |  PROJ_NETWORK=ON bin/cs2cs -d 4 --3d EPSG:4326+3855 Amersfoort | PROJ_NETWORK=ON bin/cs2cs --3d -d 4 Amersfoort "Amersfoort + NAP height"
52.0010    5.0004 0.1953

2nd example
$ echo 52 5 0 |  PROJ_NETWORK=ON bin/cs2cs -d 4 EPSG:4326+3855 "Amersfoort + NAP height"
52.0010    5.0004 0.2000


Disclaimer:
De inhoud van deze e-mail is vertrouwelijk en uitsluitend bestemd voor de geadresseerde(n).
Gebruik, openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.
Op al onze producten en diensten zijn onze algemene leveringsvoorwaarden van toepassing
[https://www.kadaster.nl/algemene-leveringsvoorwaarden].

Disclaimer:
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Our general terms and conditions of delivery apply to all our products and services
[https://www.kadaster.com/general-terms-and-conditions].

From j1 at jimenezshaw.com  Mon Feb 23 02:25:32 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Mon, 23 Feb 2026 11:25:32 +0100
Subject: [PROJ] proj in the browser
Message-ID: <CADRrdKvXevv0hNRSMW5YNUSEb4EutqWqLrfMxhHxqveeExhgaQ@mail.gmail.com>

Hi

TL;DR: go to the links below and play :)

Finally, after a long time and learning a lot during the process, I am
getting a webpage that uses PROJ to perform coordinate transformations
(similar to cs2cs), and another that replicates projinfo:

tranform: https://jjimenezshaw.github.io/wasm-proj/transform.html

projinfo: https://jjimenezshaw.github.io/wasm-proj/projinfo.html

All runs in the browser with PROJ (current master as of yesterday), no
server needed. It uses the wasm compilation with emscripten that is run in
CI (I copied the two needed files into the project).
It uses a very simple library to manage the memory allocation, trying to
make it simple for the javascript developer. The library is still in
development, but functional as you can see.

The transformer is able to use grids: it downloads at execution time the
part of grid needed (a feature PROJ already has). For that it needs some
code to run in a web worker, but the library is doing that as well.

For instance, this link
https://jjimenezshaw.github.io/wasm-proj/transform.html?st=combo&tt=combo&sh=EPSG%3A6318&th=EPSG%3A6539&tv=EPSG%3A6360&p3d=1&net=1&coords=40.7789978+-73.9632654+-20.5
uses the geoid model for NAVD88 (in this case, GEOID18)

Tip for projinfo: add "&run=1" when you share the URL, and it will run
directly the query. Both pages update the URL with the data to make it easy
to share.

Have fun!

Cheers,
Javier.

PS. Yes, another one. There are at least two other. This was a personal
challenge to efficiently use the grid files in the browser.
PPS. Why these two, and not other things from PROJ? well, these are the two
apps I use in a daily basis in the console. Now I can send a link to my
colleagues that do not know how to use the command line. But more things
can be done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260223/25906fbf/attachment.htm>

From kristian at evers.dev  Mon Feb 23 07:41:50 2026
From: kristian at evers.dev (Kristian Evers)
Date: Mon, 23 Feb 2026 15:41:50 +0000
Subject: [PROJ] Trouble building packages for distribution
Message-ID: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>

I?m in the process of preparing 9.8.0RC1 but seem to have hit a bit of an issue with CMake that I can?t make sense of.
In short, empty archives are produced when running "cmake --build . --target dist?.

As usual I follow the recipe in HOWTO-RELEASE:

$ BRANCH_NAME=9.8
$ git clone --depth 1 --branch $BRANCH_NAME https://github.com/OSGeo/PROJ.git PROJ-$BRANCH_NAME
$ cd PROJ-$BRANCH_NAME
$ mkdir _build && cd _build
$ cmake -D BUILD_TESTING=OFF ..
$ cmake --build . --target dist

Looking at the produced files shows they are empty:

$ ls -lh proj-9.8.0*
-rw-r--r--  1 kevers  staff    29B Feb 23 16:31 proj-9.8.0.tar.gz
-rw-r--r--  1 kevers  staff    22B Feb 23 16:31 proj-9.8.0.zip

Oddly enough, if I do a similar thing within my git repo I succeed:

$ mkdir build && cd build
$ cmake -D BUILD_TESTING=OFF ..
$ cmake --build . --target dist
$ ls -lh proj-*
-rw-r--r--  1 kevers  staff   6.4M Feb 23 16:38 proj-9.8.0.tar.gz
-rw-r--r--  1 kevers  staff   6.9M Feb 23 16:38 proj-9.8.0.zip

I see that a few things have changed in CMakeLists.txt but nothing that seems related. Could someone try to reproduce this? 

/Kristian

From even.rouault at spatialys.com  Mon Feb 23 08:01:01 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 23 Feb 2026 17:01:01 +0100
Subject: [PROJ] Trouble building packages for distribution
In-Reply-To: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>
References: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>
Message-ID: <4ea08fa3-fbfd-4573-9ace-94a1111c0759@spatialys.com>


Le 23/02/2026 ? 16:41, Kristian Evers via PROJ a ?crit?:
> I?m in the process of preparing 9.8.0RC1 but seem to have hit a bit of an issue with CMake that I can?t make sense of.
> In short, empty archives are produced when running "cmake --build . --target dist?.
>
> As usual I follow the recipe in HOWTO-RELEASE:
>
> $ BRANCH_NAME=9.8
> $ git clone --depth 1 --branch $BRANCH_NAMEhttps://github.com/OSGeo/PROJ.git PROJ-$BRANCH_NAME
> $ cd PROJ-$BRANCH_NAME
> $ mkdir _build && cd _build
> $ cmake -D BUILD_TESTING=OFF ..
> $ cmake --build . --target dist

Works for me:

-rw-rw-r--? 1 even even 5998670 f?vr. 23 16:59 proj-9.8.0.tar.gz
-rw-rw-r--? 1 even even 6325053 f?vr. 23 16:59 proj-9.8.0.zip

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260223/d51bbcde/attachment.htm>

From j1 at jimenezshaw.com  Mon Feb 23 08:01:50 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Mon, 23 Feb 2026 17:01:50 +0100
Subject: [PROJ] Trouble building packages for distribution
In-Reply-To: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>
References: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>
Message-ID: <CADRrdKtSu8tYB1sZ3m57t-cTjdsqtjEdfpNMsXF11PUYdE=4vg@mail.gmail.com>

I got this, but it was extremely fast compiling. I think it was using some
kind of cache

ls -lh proj-9.8.0*
-rw-rw-r-- 1 jshaw jshaw 5.8M Feb 23 16:59 proj-9.8.0.tar.gz
-rw-rw-r-- 1 jshaw jshaw 6.1M Feb 23 16:59 proj-9.8.0.zip


On Mon, 23 Feb 2026 at 16:51, Kristian Evers via PROJ <proj at lists.osgeo.org>
wrote:

> I?m in the process of preparing 9.8.0RC1 but seem to have hit a bit of an
> issue with CMake that I can?t make sense of.
> In short, empty archives are produced when running "cmake --build .
> --target dist?.
>
> As usual I follow the recipe in HOWTO-RELEASE:
>
> $ BRANCH_NAME=9.8
> $ git clone --depth 1 --branch $BRANCH_NAME
> https://github.com/OSGeo/PROJ.git PROJ-$BRANCH_NAME
> $ cd PROJ-$BRANCH_NAME
> $ mkdir _build && cd _build
> $ cmake -D BUILD_TESTING=OFF ..
> $ cmake --build . --target dist
>
> Looking at the produced files shows they are empty:
>
> $ ls -lh proj-9.8.0*
> -rw-r--r--  1 kevers  staff    29B Feb 23 16:31 proj-9.8.0.tar.gz
> -rw-r--r--  1 kevers  staff    22B Feb 23 16:31 proj-9.8.0.zip
>
> Oddly enough, if I do a similar thing within my git repo I succeed:
>
> $ mkdir build && cd build
> $ cmake -D BUILD_TESTING=OFF ..
> $ cmake --build . --target dist
> $ ls -lh proj-*
> -rw-r--r--  1 kevers  staff   6.4M Feb 23 16:38 proj-9.8.0.tar.gz
> -rw-r--r--  1 kevers  staff   6.9M Feb 23 16:38 proj-9.8.0.zip
>
> I see that a few things have changed in CMakeLists.txt but nothing that
> seems related. Could someone try to reproduce this?
>
> /Kristian
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260223/95c1cbf4/attachment.htm>

From kristian at evers.dev  Mon Feb 23 08:15:04 2026
From: kristian at evers.dev (Kristian Evers)
Date: Mon, 23 Feb 2026 16:15:04 +0000
Subject: [PROJ] Trouble building packages for distribution
In-Reply-To: <CADRrdKtSu8tYB1sZ3m57t-cTjdsqtjEdfpNMsXF11PUYdE=4vg@mail.gmail.com>
References: <0B1B3565-C329-4172-8694-5E5AD077727A@evers.dev>
 <CADRrdKtSu8tYB1sZ3m57t-cTjdsqtjEdfpNMsXF11PUYdE=4vg@mail.gmail.com>
Message-ID: <3505A069-C68E-4F2E-A203-EEF1ED4D5338@evers.dev>

I had a hunch it was a problem on my end. No clue what it is though? Probably MacOS being difficult again.

I?ve pasted the output from CMake below in case anyone can see a problem in it.

Could one of you send me a copy of the files you produced? At least I can upload those in case I don?t figure
out what?s going today.

/Kristian

$ cmake -D BUILD_TESTING=OFF ..
-- The C compiler identification is AppleClang 17.0.0.17000603
-- The CXX compiler identification is AppleClang 17.0.0.17000603
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Requiring C++17
-- Requiring C++17 - done
-- Requiring C99
-- Requiring C99 - done
-- Configuring PROJ:
-- PROJ_VERSION = 9.8.0
-- Looking for localeconv
-- Looking for localeconv - found
-- Looking for strerror
-- Looking for strerror - found
-- Looking for dladdr in dl
-- Looking for dladdr in dl - found
-- Looking for exp in m
-- Looking for exp in m - found
-- BUNDLEDIR = Applications/OSGEO
-- PROJ_INSTALL_NAME_DIR = @executable_path/../../Library/Frameworks
-- FRAMEWORKDIR = Library/Frameworks
-- nlohmann/json: internal
-- Found SQLite3: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libsqlite3.tbd (found version "3.51.0")
-- Found TIFF: /opt/homebrew/lib/libtiff.dylib (found version "4.7.1")
-- Found CURL: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libcurl.tbd (found version "8.7.1")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Testing disabled
-- Configuring proj library:
-- ENABLE_IPO = OFF
-- PROJ_OUTPUT_NAME = proj
-- BUILD_SHARED_LIBS = ON
-- PROJ_LIBRARIES = proj
-- PROJ: Configured 'dist' target
-- EMBED_RESOURCE_FILES=OFF
-- Configuring done (2.4s)
-- Generating done (0.1s)
-- Build files have been written to: /Users/kevers/dev/proj/build/PROJ-9.8/_build

$ cmake --build . --target dist
Run CPack packaging tool for source...
CPack: Create package using TGZ
CPack: Install projects
CPack: - Install directory: /Users/kevers/dev/proj/build/PROJ-9.8
CPack: Create package
CPack: - package: /Users/kevers/dev/proj/build/PROJ-9.8/_build/proj-9.8.0.tar.gz generated.
CPack: Create package using ZIP
CPack: Install projects
CPack: - Install directory: /Users/kevers/dev/proj/build/PROJ-9.8
CPack: Create package
CPack: - package: /Users/kevers/dev/proj/build/PROJ-9.8/_build/proj-9.8.0.zip generated.
Built target dist

$ ls -lh proj-*
-rw-r--r-- 1 kevers staff 29B Feb 23 16:31 proj-9.8.0.tar.gz
-rw-r--r-- 1 kevers staff 22B Feb 23 16:31 proj-9.8.0.zip

> On 23 Feb 2026, at 17.01, Javier Jimenez Shaw <j1 at jimenezshaw.com> wrote:
>
> I got this, but it was extremely fast compiling. I think it was using some kind of cache
>
> ls -lh proj-9.8.0*
> -rw-rw-r-- 1 jshaw jshaw 5.8M Feb 23 16:59 proj-9.8.0.tar.gz
> -rw-rw-r-- 1 jshaw jshaw 6.1M Feb 23 16:59 proj-9.8.0.zip
>
> On Mon, 23 Feb 2026 at 16:51, Kristian Evers via PROJ <proj at lists.osgeo.org> wrote:
>
>> I?m in the process of preparing 9.8.0RC1 but seem to have hit a bit of an issue with CMake that I can?t make sense of.
>> In short, empty archives are produced when running "cmake --build . --target dist?.
>>
>> As usual I follow the recipe in HOWTO-RELEASE:
>>
>> $ BRANCH_NAME=9.8
>> $ git clone --depth 1 --branch $BRANCH_NAME https://github.com/OSGeo/PROJ.git PROJ-$BRANCH_NAME
>> $ cd PROJ-$BRANCH_NAME
>> $ mkdir _build && cd _build
>> $ cmake -D BUILD_TESTING=OFF ..
>> $ cmake --build . --target dist
>>
>> Looking at the produced files shows they are empty:
>>
>> $ ls -lh proj-9.8.0*
>> -rw-r--r-- 1 kevers staff 29B Feb 23 16:31 proj-9.8.0.tar.gz
>> -rw-r--r-- 1 kevers staff 22B Feb 23 16:31 proj-9.8.0.zip
>>
>> Oddly enough, if I do a similar thing within my git repo I succeed:
>>
>> $ mkdir build && cd build
>> $ cmake -D BUILD_TESTING=OFF ..
>> $ cmake --build . --target dist
>> $ ls -lh proj-*
>> -rw-r--r-- 1 kevers staff 6.4M Feb 23 16:38 proj-9.8.0.tar.gz
>> -rw-r--r-- 1 kevers staff 6.9M Feb 23 16:38 proj-9.8.0.zip
>>
>> I see that a few things have changed in CMakeLists.txt but nothing that seems related. Could someone try to reproduce this?
>>
>> /Kristian
>> _______________________________________________
>> PROJ mailing list
>> PROJ at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260223/d0d904f7/attachment-0001.htm>

From kristian at evers.dev  Mon Feb 23 08:45:53 2026
From: kristian at evers.dev (Kristian Evers)
Date: Mon, 23 Feb 2026 16:45:53 +0000
Subject: [PROJ] PROJ 9.8.0RC1
Message-ID: <85862C62-90FA-4DF1-952E-8D43B89063C6@evers.dev>

All,

In preparation for a new PROJ release I have uploaded release candidate for the packages.
We haven?t had any new grids submitted to PROJ-data since the last release of PROJ, so for
the first time in a long time the PROJ release will stand on its own.

Download the archives here: 

https://download.osgeo.org/proj/proj-9.8.0RC1.tar.gz
https://download.osgeo.org/proj/proj-9.8.0RC1.zip

The release candidate includes both updates and bug fixes. Release notes below.

Please test the release candidates and report any issues you may find with them.
Either here on the mailing list or on GitHub.

/Kristian

????????????????????????????????????????


# PROJ Release Notes

## 9.8.0

### Updates

* Database: update to EPSG v12.049 (#4671)

* Database: update ESRI records to ArcGIS Pro 3.6 (#4622)

* Support for Canadian vertical references MTM CGVD2013 epoch 1997, 2002, 2010 and
UTM CGVD28 epoch 1997, 2002, 2010 (#4623)

* `createOperationsCompoundToGeog()`: improvement to make "PNG94 / PNGMG94 zone 54 + Kumul
34 height" to "WGS 84 (G2139)" perform vertical transformation (#4624)

* Remove hardcoding of 'ETRS89-NOR [EUREF89]' cases and generalize it to other ETRS89-XXX
cases (#4625)

* Database: create ESRI aliases for geodetic_datum and geodetic_crs even if they are the
same as EPSG ones (#4626)

* Use Emscripten fetch in networkfilemanager (#4627)

* `ProjectedCRS::identify()`: do not return CRS whose ellipsoid is totally different from the input one (#4635)

* respect `CRS_EXTENT_USE=NONE` for ConcatenatedOperations (#4652)

* Add support for Equidistant Cylindrical ellipsoidal method (EPSG:1028) (#4656)

* Update `proj_symbol_rename.h` (#4657)

* WKT1 importer: deal with 'VERT_CS["Geoid 2012A",' (#4659)

* Generate correct library name in `proj.pc` (#4660)

* Derived projected CRS related improvements (#4667)

* ETRS89-xxx to ETRS89-yyy related improvements (#4668)

* `createCoordinateOperation()`: tune computed accuracy of a concatenated op within ETRS89 (#4670)

* `createOperationsCompoundToGeog()`: discard 2D-only transformations from interpolation
3D CRS to target 3D CRS (#4677)


### Bug Fixes

* CRS identification: fix issue when identifying WKT from older EPSG releases with newer
ones where the ETRS89-XXX national datums have been added (#4600)

* fix `normalizeForVisualization` to skip extent checks for axis-swap operations (#4632)

* Improvements to TRACE_FETCH debug messages (#4645)

* tmerc spherical: fix numeric instability at lat=lat_0 (#4674)



From gdt at lexort.com  Mon Feb 23 10:42:31 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 23 Feb 2026 13:42:31 -0500
Subject: [PROJ] PROJ 9.8.0RC1
In-Reply-To: <85862C62-90FA-4DF1-952E-8D43B89063C6@evers.dev> (Kristian Evers
 via PROJ's message of "Mon, 23 Feb 2026 16:45:53 +0000")
References: <85862C62-90FA-4DF1-952E-8D43B89063C6@evers.dev>
Message-ID: <rmia4wzxpwo.fsf@s1.lexort.com>

Kristian Evers via PROJ <proj at lists.osgeo.org> writes:

> https://download.osgeo.org/proj/proj-9.8.0RC1.tar.gz

* Tests pass on NetBSD 11 amd64.

* Tests pass on NetBSD 10 amd64.

* Tests pass on NetBSD 9 i386.

  Running tess with 9.7.1 installed failed a bunch of them.  It's
  possible pkgsrc is at cross purposes with RPATH handling for running
  tests on not installed code, and possible the test harness is off.
  (It's also surprising that new tests are so troubled on the old
  library.)

* (tests on NetBSD 9 earmv7hf-el and 10 aarch64 in progress)

* This installs a new header, but it is not mentioned in NEWS.  I don't
  know if this is a NEWS bug or an install system bug.

  $prefix/include/projapps_lib.h

* I'm still carrying a patch to fix cmake using a gcc warning flag not
  recognized by earlier gcc (specifically 7).  Without this the build
  fails on e.g. NetBSD 9 i386.

  I would suggest either just applying this patch to proj (removing
  adding the warning), or doing the cmake equivalent of an autoconf test
  to see if the compiler is ok with the flag, and add it if so.

  $ cat patches/patch-CMakeLists.txt 
  $NetBSD: patch-CMakeLists.txt,v 1.5 2025/09/23 22:38:44 gdt Exp $

  Omit a warning that is unrecognized on gcc 7.

  Sent upstream by email.

  --- CMakeLists.txt.orig 2025-09-23 22:12:59.828352847 +0000
  +++ CMakeLists.txt
  @@ -72,7 +72,6 @@ if("${CMAKE_C_COMPILER_ID}" STREQUAL "GN
       # -Wold-style-cast
       -Woverloaded-virtual
       -Wzero-as-null-pointer-constant
  -    -Wdeprecated-copy-dtor
     )
   elseif("${CMAKE_C_COMPILER_ID}" MATCHES "Clang")
     set(PROJ_common_WARN_FLAGS ${PROJ_common_WARN_FLAGS}

From knudsen.thomas at gmail.com  Mon Feb 23 12:27:25 2026
From: knudsen.thomas at gmail.com (Thomas Knudsen)
Date: Mon, 23 Feb 2026 21:27:25 +0100
Subject: [PROJ] proj in the browser
In-Reply-To: <CADRrdKvXevv0hNRSMW5YNUSEb4EutqWqLrfMxhHxqveeExhgaQ@mail.gmail.com>
References: <CADRrdKvXevv0hNRSMW5YNUSEb4EutqWqLrfMxhHxqveeExhgaQ@mail.gmail.com>
Message-ID: <CAH0YoENObcuGG_y-ea-APnUc8_Oqh35nmAxCKXW6EttBFrH0cQ@mail.gmail.com>

Whoa, Javier! That is utterly awesome!

I needed this badly a few months back, when teaching a geodesy course for
people who would never consider installing PROJ on their PC. Next time
around, I will just point them to your work.

Thanks for this huge effort!

/Thomas Knudsen

Den man. 23. feb. 2026 kl. 11.25 skrev Javier Jimenez Shaw via PROJ <
proj at lists.osgeo.org>:

> Hi
>
> TL;DR: go to the links below and play :)
>
> Finally, after a long time and learning a lot during the process, I am
> getting a webpage that uses PROJ to perform coordinate transformations
> (similar to cs2cs), and another that replicates projinfo:
>
> tranform: https://jjimenezshaw.github.io/wasm-proj/transform.html
>
> projinfo: https://jjimenezshaw.github.io/wasm-proj/projinfo.html
>
> All runs in the browser with PROJ (current master as of yesterday), no
> server needed. It uses the wasm compilation with emscripten that is run in
> CI (I copied the two needed files into the project).
> It uses a very simple library to manage the memory allocation, trying to
> make it simple for the javascript developer. The library is still in
> development, but functional as you can see.
>
> The transformer is able to use grids: it downloads at execution time the
> part of grid needed (a feature PROJ already has). For that it needs some
> code to run in a web worker, but the library is doing that as well.
>
> For instance, this link
> https://jjimenezshaw.github.io/wasm-proj/transform.html?st=combo&tt=combo&sh=EPSG%3A6318&th=EPSG%3A6539&tv=EPSG%3A6360&p3d=1&net=1&coords=40.7789978+-73.9632654+-20.5
> uses the geoid model for NAVD88 (in this case, GEOID18)
>
> Tip for projinfo: add "&run=1" when you share the URL, and it will run
> directly the query. Both pages update the URL with the data to make it easy
> to share.
>
> Have fun!
>
> Cheers,
> Javier.
>
> PS. Yes, another one. There are at least two other. This was a personal
> challenge to efficiently use the grid files in the browser.
> PPS. Why these two, and not other things from PROJ? well, these are the
> two apps I use in a daily basis in the console. Now I can send a link to my
> colleagues that do not know how to use the command line. But more things
> can be done.
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260223/38371129/attachment.htm>

From andreaerdna at libero.it  Tue Feb 24 01:35:32 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Tue, 24 Feb 2026 10:35:32 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
Message-ID: <d9f86adc-f850-4004-b1f0-bbe26437f737@libero.it>

Hi list,
I've noticed a behaviour of cs2cs and projinfo (PRJ 9.7.1 / OSGeo4W) 
that I'm having trouble understanding (probably because I don't usually 
use them).

Trying to reproject a point in Italy, say 620000 4540000 EPSG:23033 to 
EPSG:25833:

projinfo -s EPSG:23033 -t EPSG:25833 -o PROJ

returns 1 operation that is a simple ballpark operation with unknown 
declared accuracy

+proj=pipeline
   +step +inv +proj=utm +zone=33 +ellps=intl
   +step +proj=utm +zone=33 +ellps=GRS80


projinfo -s EPSG:23033 -t EPSG:25833 -o PROJ --spatial-test intersects

returns 3 operations: the first 2 ones are Helmert with different 
parameters for Norway and Denmark and 1 meter accuracy declared and the 
third one is the same ballpark operation;

echo 620000 4540000 | cs2cs EPSG:23033 EPSG:25833

returns

619994.54       4539920.85 0.00

i.e. cs2cs is using the ballpark operation (probably because the point 
is outside the area of use of the first two ones).

Trying to reproject the same point 620000 4540000 EPSG:23033 to EPSG:3065:

projinfo -s EPSG:23033 -t EPSG:3065 -o PROJ

returns the same simple ballpark operation;

projinfo -s EPSG:23033 -t EPSG:3065 -o PROJ --spatial-test intersects

returns 2 operations: the first one uses a NTv2 grid shift file which is 
not available, the second one is the same ballpark operation;

echo 620000 4540000 | cs2cs EPSG:23033 EPSG:3065

returns

619926.95       4539810.94 0.00

So... in this case I wonder which operation is used by cs2cs: the first 
one should not be usable because the grid shift file is not available, 
whereas if the second one was used, I guess it should have returned the 
same result as EPSG:23033 to EPSG:3065.

For EPSG:23033 to EPSG:25833, QGIS lists the same 3 operations listed by 
projinfo with "--spatial-test intersects" but it considers the first one 
as the preferred one (whereas cs2cs uses the third one); for EPSG:23033 
to EPSG:3065, it lists the same 2 operations listed by projinfo with 
--spatial-test intersects, but it uses the second one since the grid 
shift file needed for the first one is not available (whereas I don't 
understand which operation is used by cs2cs).

Even stranger for me is the case of EPSG:23033 to EPSG:6708...

Could someone help me understanding such behaviours?

Regards.

Andrea Giudiceandrea

From kristian at evers.dev  Tue Feb 24 02:25:19 2026
From: kristian at evers.dev (Kristian Evers)
Date: Tue, 24 Feb 2026 10:25:19 +0000
Subject: [PROJ] PROJ 9.8.0RC1
In-Reply-To: <rmia4wzxpwo.fsf@s1.lexort.com>
References: <85862C62-90FA-4DF1-952E-8D43B89063C6@evers.dev>
 <rmia4wzxpwo.fsf@s1.lexort.com>
Message-ID: <aINBwiGVxSI3iQBfYgRLvSuXDkiMhS7aHaqaX81mDdKcPQRDS2eZVbzYjUOStWu6XZUkU6EIKcjJ7ivhK6Ld2k1TF_NMNQooYXTni9VaBkY=@evers.dev>

Thanks, Greg.

The header was a NEWS bug - the pull request wasn't tagged for inclusion in this release so my news generator script didn't catch it. I've added it now. Mike has kindly fixed the gcc warnings in https://github.com/OSGeo/PROJ/pull/4679/.

I'll put out RC2 tomorrow.

/Kristian

On Monday, February 23rd, 2026 at 19:42, Greg Troxel via PROJ <proj at lists.osgeo.org> wrote:

> Kristian Evers via PROJ <proj at lists.osgeo.org> writes:
> 
> > https://download.osgeo.org/proj/proj-9.8.0RC1.tar.gz
> 
> * Tests pass on NetBSD 11 amd64.
> 
> * Tests pass on NetBSD 10 amd64.
> 
> * Tests pass on NetBSD 9 i386.
> 
>   Running tess with 9.7.1 installed failed a bunch of them.  It's
>   possible pkgsrc is at cross purposes with RPATH handling for running
>   tests on not installed code, and possible the test harness is off.
>   (It's also surprising that new tests are so troubled on the old
>   library.)
> 
> * (tests on NetBSD 9 earmv7hf-el and 10 aarch64 in progress)
> 
> * This installs a new header, but it is not mentioned in NEWS.  I don't
>   know if this is a NEWS bug or an install system bug.
> 
>   $prefix/include/projapps_lib.h
> 
> * I'm still carrying a patch to fix cmake using a gcc warning flag not
>   recognized by earlier gcc (specifically 7).  Without this the build
>   fails on e.g. NetBSD 9 i386.
> 
>   I would suggest either just applying this patch to proj (removing
>   adding the warning), or doing the cmake equivalent of an autoconf test
>   to see if the compiler is ok with the flag, and add it if so.
> 
>   $ cat patches/patch-CMakeLists.txt
>   $NetBSD: patch-CMakeLists.txt,v 1.5 2025/09/23 22:38:44 gdt Exp $
> 
>   Omit a warning that is unrecognized on gcc 7.
> 
>   Sent upstream by email.
> 
>   --- CMakeLists.txt.orig 2025-09-23 22:12:59.828352847 +0000
>   +++ CMakeLists.txt
>   @@ -72,7 +72,6 @@ if("${CMAKE_C_COMPILER_ID}" STREQUAL "GN
>        # -Wold-style-cast
>        -Woverloaded-virtual
>        -Wzero-as-null-pointer-constant
>   -    -Wdeprecated-copy-dtor
>      )
>    elseif("${CMAKE_C_COMPILER_ID}" MATCHES "Clang")
>      set(PROJ_common_WARN_FLAGS ${PROJ_common_WARN_FLAGS}
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
> 

From even.rouault at spatialys.com  Tue Feb 24 02:27:07 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 24 Feb 2026 11:27:07 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
In-Reply-To: <d9f86adc-f850-4004-b1f0-bbe26437f737@libero.it>
References: <d9f86adc-f850-4004-b1f0-bbe26437f737@libero.it>
Message-ID: <9f2fa7ff-dbc7-485f-ac1b-98a9f2434105@spatialys.com>

Andrea,

>
> So... in this case I wonder which operation is used by cs2cs: the 
> first one should not be usable because the grid shift file is not 
> available, whereas if the second one was used, I guess it should have 
> returned the same result as EPSG:23033 to EPSG:3065.

Not a dumb question at all. There's indeed a subtlety involved. cs2cs 
does internally the equivalent of projinfo "--grid-check 
discard_missing" if the PROJ_NETWORK=ON environment variable is not set. 
That is it won't bother consider grids that aren't available on the 
system. When?"--grid-check discard_missing" is added , you'll see the 
following operation

""""

unknown id, Inverse of UTM zone 33N + ED50 to WGS 84 (1) + Inverse of 
ETRS89-ITA [IGM95] to WGS 84 (1) + UTM zone 33N, 11 m, unknown domain of 
validity

PROJ string:
+proj=pipeline
 ? +step +inv +proj=utm +zone=33 +ellps=intl
 ? +step +proj=push +v_3
 ? +step +proj=cart +ellps=intl
 ? +step +proj=helmert +x=-87 +y=-98 +z=-121
 ? +step +inv +proj=cart +ellps=GRS80
 ? +step +proj=pop +v_3
 ? +step +proj=utm +zone=33 +ellps=GRS80
"""

and that's the one used by cs2cs, as you can see when 
setting?PROJ_DEBUG=2 (here's done the Bash way. On windows cmd, do "set 
PROJ_DEBUG=2" before)

$ echo 620000 4540000 | PROJ_DEBUG=2 bin/cs2cs EPSG:23033 EPSG:3065
pj_open_lib(proj.ini): call 
fopen(/home/even/proj/install-proj-master/share/proj/proj.ini) - succeeded
pj_open_lib(proj.db): call 
fopen(/home/even/proj/install-proj-master/share/proj/proj.db) - succeeded
pj_open_lib(35160622_47161840_E50_F89.gsb): call 
fopen(35160622_47161840_E50_F89.gsb) - failed
pj_open_lib(35160622_47161840_F89_F00.gsb): call 
fopen(35160622_47161840_F89_F00.gsb) - failed
pj_open_lib(35160622_47161840_E50_F00.gsb): call 
fopen(35160622_47161840_E50_F00.gsb) - failed
pj_open_lib(35160622_47161840_R40_F89.gsb): call 
fopen(35160622_47161840_R40_F89.gsb) - failed
pj_open_lib(35160622_47161840_R40_E50.gsb): call 
fopen(35160622_47161840_R40_E50.gsb) - failed
Using coordinate operation Inverse of UTM zone 33N + ED50 to WGS 84 (1) 
+ Inverse of ETRS89-ITA [IGM95] to WGS 84 (1) + UTM zone 33N
619926.95? ? 4539810.94 0.00

So basically it goes through a WGS84 intermediate and uses a Helmert 
transformation that is an average for the whole ED50 datum (not 
optimized for Italy), following by a null geographic offset between 
WGS84 and IGM95.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From andreaerdna at libero.it  Tue Feb 24 04:23:09 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Tue, 24 Feb 2026 13:23:09 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
Message-ID: <f5180b91-14b9-41c0-b679-9d060fa9356a@libero.it>

Thank you very much, Even. Your explanation clarifies all my doubts!

Regards.

Andrea

From andreaerdna at libero.it  Tue Feb 24 05:00:13 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Tue, 24 Feb 2026 14:00:13 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
Message-ID: <6adb9c77-b5ec-4ad0-b03a-50d0b944cad8@libero.it>

Il 24/02/2026 13:23, Andrea Giudiceandrea ha scritto:
> Thank you very much, Even. Your explanation clarifies all my doubts!

Actually, not exactly all...

I wonder why In QGIS the listed transformations available for EPSG:23033 
-> EPSG:3065 are only 2 (1 grid, 1 ballpark, corresponding to projinfo 
without "--grid-check discard_missing") instead of the 6 (5 Helmert, 1 
ballpark) listed by projinfo with "--grid-check discard_missing" or a 
union of both (1 grid shift, 5 Helmert and 1 ballpark).

This creates a discrepancy, making QGIS use a ballpark transformation 
whereas a better one could be used.

Maybe it would be useful if QGIS could list and let the user choose 
among all the available transformations, wouldn't it?

Regards.

Andrea

From even.rouault at spatialys.com  Tue Feb 24 05:11:47 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 24 Feb 2026 14:11:47 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
In-Reply-To: <6adb9c77-b5ec-4ad0-b03a-50d0b944cad8@libero.it>
References: <6adb9c77-b5ec-4ad0-b03a-50d0b944cad8@libero.it>
Message-ID: <d1fac67d-70a6-448a-a052-50039dad3f03@spatialys.com>


Le 24/02/2026 ? 14:00, Andrea Giudiceandrea via PROJ a ?crit?:
> Il 24/02/2026 13:23, Andrea Giudiceandrea ha scritto:
>> Thank you very much, Even. Your explanation clarifies all my doubts!
>
> Actually, not exactly all...
>
> I wonder why In QGIS the listed transformations available for 
> EPSG:23033 -> EPSG:3065 are only 2 (1 grid, 1 ballpark, corresponding 
> to projinfo without "--grid-check discard_missing") instead of the 6 
> (5 Helmert, 1 ballpark) listed by projinfo with "--grid-check 
> discard_missing" or a union of both (1 grid shift, 5 Helmert and 1 
> ballpark).
>
> This creates a discrepancy, making QGIS use a ballpark transformation 
> whereas a better one could be used.
>
> Maybe it would be useful if QGIS could list and let the user choose 
> among all the available transformations, wouldn't it?

This is a case where one could argue which one is the best between the 
ballpark ED50 -> IGM95 or going through WGS 84 by using a likely poorly 
conditionned Helmert transformation. Both results are right and wrong to 
some accuracy requirements...

Why IGM is still not releasing freely their grids ? (I remember doing 
them some education in Firenze in 2022 ...)

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From andreaerdna at libero.it  Tue Feb 24 06:32:08 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Tue, 24 Feb 2026 15:32:08 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
Message-ID: <38339542-4271-4984-8a12-c22f906a1902@libero.it>

Il 24/02/2026 14:11, Even Rouault ha scritto:
> Why IGM is still not releasing freely their grids ? (I remember doing 
> them some education in Firenze in 2022 ...)

 > This is a case where one could argue which one is the best between the
 > ballpark ED50 -> IGM95 or going through WGS 84 by using a likely poorly
 > conditionned Helmert transformation. Both results are right and wrong to
 > some accuracy requirements...


You are perfectly right. I'm well aware of the issue. IGM sells the 
grids, and, until now, it has not wanted to give up such income making 
them freely available...
Some unofficial grid shift files for Italy are however publicity 
available, which have the same precision of the official ones, but their 
licence and legality is not clear.

Anyway, my concerns and doubts were firstly related to just 
understanding the reason why (although they all use the same PROJ and 
proj.db), cs2cs (and PostGIS and SpatiaLite) uses a particular (better) 
transformation, whereas QGIS another (worst) one, regardless of the fact 
that any of such transformations could be considered the right one.

For that transformation, however, all the 5 available Helmert 
operations, the first one of which is used by cs2cs (and PostGIS and 
SpatiaLite), are much better than the ballpark operation used by QGIS 
(which can only choose between the grid shift operation and the ballpark 
one), since the ballpark is more than 100 metres off.

Regards.

Andrea

From j1 at jimenezshaw.com  Tue Feb 24 07:34:34 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Tue, 24 Feb 2026 16:34:34 +0100
Subject: [PROJ] Problems with sqlite3 and disk
Message-ID: <CADRrdKsc-7L916OH8PCDqC5sC9hsFcwB4o1S35uzwHQyLFwf6A@mail.gmail.com>

Hi

We are having problems with sqlite3 and disk while running on iOS. It
happens only from time to time. Restarting the application is usually
enough.

The first case returns an sqlite3 error 13: "database or disk is full"
https://sqlite.org/rescode.html#full
This is the message (trimmed)

Fatal Exception: osgeo::proj::io::FactoryException
SQLite error [ code = 13, msg = database or disk is full ] on SELECT *
FROM (SELECT
c.auth_name, c.code, c.name, c.type, c.deprecated, a.west_lon,
a.south_lat, a.east_lon,
a.north_lat, a.description, NULL, cb.name FROM geodetic_crs c LEFT
JOIN usage u ON
u.object_table_name = 'geodetic_crs'...

And this is the stack trace

8  libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16
9  libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86
10 libc++abi.dylib 0x152bc
__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90
11 proj 0x168434 osgeo::proj::io::SQLiteHandle::run(sqlite3_stmt*,
std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char>> const&,
std::__1::list<osgeo::proj::io::SQLValues,
std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1468
12 proj 0x16a6e8
osgeo::proj::io::DatabaseContext::Private::run(std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char>> const&,
std::__1::list<osgeo::proj::io::SQLValues,
std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1220
13 proj 0x1ad76c osgeo::proj::io::AuthorityFactory::getCRSInfoList()
const + 2332
...


There is another similar (but different) issue with error 10: "disk I/O
error" https://sqlite.org/rescode.html#ioerr

Fatal Exception: osgeo::proj::io::FactoryException
SQLite error [ code = 10, msg = disk I/O error ] on SELECT name FROM
"geodetic_datum" WHERE auth_name = ? AND code = ?


Stack trace

9  libc++abi.dylib 0x11b80 std::terminate() + 108

10 proj 0x8270 __clang_call_terminate + 14
11 proj 0xad1e8
osgeo::proj::common::IdentifiedObject::_isEquivalentTo(osgeo::proj::common::IdentifiedObject
const*, osgeo::proj::util::IComparable::Criterion,
std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const +
234
12 proj 0xe82f4
osgeo::proj::datum::Datum::_isEquivalentTo(osgeo::proj::util::IComparable
const*, osgeo::proj::util::IComparable::Criterion,
std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const +
100
13 proj 0xed7ac
osgeo::proj::datum::GeodeticReferenceFrame::isEquivalentToNoExactTypeCheck(osgeo::proj::util::IComparable
const*, osgeo::proj::util::IComparable::Criterion,
std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const +
96
14 proj 0xc0774
osgeo::proj::crs::SingleCRS::baseIsEquivalentTo(osgeo::proj::util::IComparable
const*, osgeo::proj::util::IComparable::Criterion,
std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const +
456
15 proj 0xc8eb0
osgeo::proj::crs::GeographicCRS::_isEquivalentTo(osgeo::proj::util::IComparable
const*, osgeo::proj::util::IComparable::Criterion,
std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const +
172
16 proj 0xc627c
osgeo::proj::crs::GeodeticCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory>
const&) const + 724
17 proj 0xd072c
osgeo::proj::crs::ProjectedCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory>
const&) const + 1184
18 proj 0xd4028
osgeo::proj::crs::ProjectedCRS::_identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory>
const&) const + 44
...


Are we writing anything to disk at runtime related to sqlite3? Even a
temporary file? Where?
If yes, would this problem be fixed if we embed proj.db in the library?
Currently we are using it as an external file.

My only guess would be that sqlite3 is creating a temporary file in a
folder with very little space (like /tmp), because the phone should have a
lot of free space for normal storage.

Thank you
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260224/800347c8/attachment.htm>

From even.rouault at spatialys.com  Tue Feb 24 07:49:37 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 24 Feb 2026 16:49:37 +0100
Subject: [PROJ] Problems with sqlite3 and disk
In-Reply-To: <CADRrdKsc-7L916OH8PCDqC5sC9hsFcwB4o1S35uzwHQyLFwf6A@mail.gmail.com>
References: <CADRrdKsc-7L916OH8PCDqC5sC9hsFcwB4o1S35uzwHQyLFwf6A@mail.gmail.com>
Message-ID: <4bbb1c48-d026-47bf-abd6-6e9029eb71e8@spatialys.com>

Javier,

we don't explicitly write temporary files, but sqlite3 can decide to do 
so (typically for a "heavy" request like listing all CRS with an order 
clause in it). https://sqlite.org/c3ref/temp_directory.html mentions 
"SQLite performs a search for an appropriate temporary file 
directory.".? ?Not very helpful. Source code at 
https://github.com/sqlite/sqlite/blob/da67225f04ad0470b54433fee31baf266e6630ef/src/os_unix.c#L6262 
shows it tries in that order (for Unix systems): SQLITE_TMPDIR env var, 
TMPDIR env var, /var/tmp, /usr/tmp, /tmp and "."

For the embed proj.db, we have 
https://github.com/OSGeo/PROJ/blob/master/src/memvfs.c#L300? , which 
basically redirects to the above logic

Even

Le 24/02/2026 ? 16:34, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> We are having problems with sqlite3 and disk while running on iOS. It 
> happens only from time to time. Restarting the application is usually 
> enough.
>
> The first case returns an sqlite3 error 13: "database or disk is full" 
> https://sqlite.org/rescode.html#full
> This is the message (trimmed)
> Fatal Exception:osgeo::proj::io::FactoryException
> SQLite error [ code = 13, msg = database or disk is full ] on SELECT * FROM (SELECT
> c.auth_name, c.code,c.name <http://c.name>, c.type, c.deprecated, a.west_lon, a.south_lat, a.east_lon,
> a.north_lat, a.description, NULL,cb.name <http://cb.name> FROM geodetic_crs c LEFT JOIN usage u ON
> u.object_table_name = 'geodetic_crs'...
>
> And this is the stack trace
> 8  libc++abi.dylib 0x11bdcstd::__terminate(void (*)()) + 16
> 9  libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86
> 10 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90
> 11 proj 0x168434osgeo::proj::io::SQLiteHandle::run(sqlite3_stmt*,std::__1::basic_string<char,std::__1::char_traits<char>,std::__1::allocator<char>> const&,std::__1::list<osgeo::proj::io::SQLValues,std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1468
> 12 proj 0x16a6e8osgeo::proj::io::DatabaseContext::Private::run(std::__1::basic_string<char,std::__1::char_traits<char>,std::__1::allocator<char>> const&,std::__1::list<osgeo::proj::io::SQLValues,std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1220
> 13 proj 0x1ad76cosgeo::proj::io::AuthorityFactory::getCRSInfoList() const + 2332
> ...
>
> There is another similar (but different) issue with error 10: "disk 
> I/O error" https://sqlite.org/rescode.html#ioerr
> Fatal Exception:osgeo::proj::io::FactoryException
> SQLite error [ code = 10, msg = disk I/O error ] on SELECT name FROM "geodetic_datum" WHERE auth_name = ? AND code = ?
>
> Stack trace
>
> 9 libc++abi.dylib 0x11b80 std::terminate() + 108
> 10 proj 0x8270 __clang_call_terminate + 14
> 11 proj 0xad1e8 
> osgeo::proj::common::IdentifiedObject::_isEquivalentTo(osgeo::proj::common::IdentifiedObject 
> const*, osgeo::proj::util::IComparable::Criterion, 
> std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 
> 234 12 proj 0xe82f4 
> osgeo::proj::datum::Datum::_isEquivalentTo(osgeo::proj::util::IComparable 
> const*, osgeo::proj::util::IComparable::Criterion, 
> std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 
> 100 13 proj 0xed7ac 
> osgeo::proj::datum::GeodeticReferenceFrame::isEquivalentToNoExactTypeCheck(osgeo::proj::util::IComparable 
> const*, osgeo::proj::util::IComparable::Criterion, 
> std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 
> 96 14 proj 0xc0774 
> osgeo::proj::crs::SingleCRS::baseIsEquivalentTo(osgeo::proj::util::IComparable 
> const*, osgeo::proj::util::IComparable::Criterion, 
> std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 
> 456 15 proj 0xc8eb0 
> osgeo::proj::crs::GeographicCRS::_isEquivalentTo(osgeo::proj::util::IComparable 
> const*, osgeo::proj::util::IComparable::Criterion, 
> std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 
> 172 16 proj 0xc627c 
> osgeo::proj::crs::GeodeticCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> 
> const&) const + 724 17 proj 0xd072c 
> osgeo::proj::crs::ProjectedCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> 
> const&) const + 1184 18 proj 0xd4028 
> osgeo::proj::crs::ProjectedCRS::_identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> 
> const&) const + 44 ...
>
> Are we writing anything?to disk at runtime related to sqlite3? Even a 
> temporary file? Where?
> If yes, would this problem be fixed if we embed proj.db in the 
> library? Currently we are using it as an external file.
>
> My only guess would be that sqlite3 is creating a temporary file in a 
> folder with very little space (like /tmp), because the phone should 
> have a lot of free space for normal storage.
>
> Thank you
> Javier.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260224/bdda8954/attachment-0001.htm>

From j1 at jimenezshaw.com  Tue Feb 24 08:27:27 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Tue, 24 Feb 2026 17:27:27 +0100
Subject: [PROJ] Problems with sqlite3 and disk
In-Reply-To: <4bbb1c48-d026-47bf-abd6-6e9029eb71e8@spatialys.com>
References: <CADRrdKsc-7L916OH8PCDqC5sC9hsFcwB4o1S35uzwHQyLFwf6A@mail.gmail.com>
 <4bbb1c48-d026-47bf-abd6-6e9029eb71e8@spatialys.com>
Message-ID: <CADRrdKtL1Rxhw2okdTBN-HVQ-ohnnA39AJ8GFhqKr3ZV37MxLQ@mail.gmail.com>

Thank you Even. It was very helpful.
We will try to monitor those locations and their free space.
FYI, this was the what I wanted to diagnose with the PR
https://github.com/OSGeo/PROJ/pull/4553 ... and it worked! (the diagnostic
of the error message).

Cheers
Javier

On Tue, 24 Feb 2026 at 16:49, Even Rouault <even.rouault at spatialys.com>
wrote:

> Javier,
>
> we don't explicitly write temporary files, but sqlite3 can decide to do so
> (typically for a "heavy" request like listing all CRS with an order clause
> in it). https://sqlite.org/c3ref/temp_directory.html mentions "SQLite
> performs a search for an appropriate temporary file directory.".   Not very
> helpful. Source code at
> https://github.com/sqlite/sqlite/blob/da67225f04ad0470b54433fee31baf266e6630ef/src/os_unix.c#L6262
> shows it tries in that order (for Unix systems): SQLITE_TMPDIR env var,
> TMPDIR env var, /var/tmp, /usr/tmp, /tmp and "."
>
> For the embed proj.db, we have
> https://github.com/OSGeo/PROJ/blob/master/src/memvfs.c#L300  , which
> basically redirects to the above logic
>
> Even
> Le 24/02/2026 ? 16:34, Javier Jimenez Shaw via PROJ a ?crit :
>
> Hi
>
> We are having problems with sqlite3 and disk while running on iOS. It
> happens only from time to time. Restarting the application is usually
> enough.
>
> The first case returns an sqlite3 error 13: "database or disk is full"
> https://sqlite.org/rescode.html#full
> This is the message (trimmed)
>
> Fatal Exception: osgeo::proj::io::FactoryException
> SQLite error [ code = 13, msg = database or disk is full ] on SELECT * FROM (SELECT
> c.auth_name, c.code, c.name, c.type, c.deprecated, a.west_lon, a.south_lat, a.east_lon,
> a.north_lat, a.description, NULL, cb.name FROM geodetic_crs c LEFT JOIN usage u ON
> u.object_table_name = 'geodetic_crs'...
>
>
> And this is the stack trace
>
> 8  libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16
> 9  libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86
> 10 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90
> 11 proj 0x168434 osgeo::proj::io::SQLiteHandle::run(sqlite3_stmt*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::list<osgeo::proj::io::SQLValues, std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1468
> 12 proj 0x16a6e8 osgeo::proj::io::DatabaseContext::Private::run(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::list<osgeo::proj::io::SQLValues, std::__1::allocator<osgeo::proj::io::SQLValues>> const&, bool) + 1220
> 13 proj 0x1ad76c osgeo::proj::io::AuthorityFactory::getCRSInfoList() const + 2332
> ...
>
>
> There is another similar (but different) issue with error 10: "disk I/O
> error" https://sqlite.org/rescode.html#ioerr
>
> Fatal Exception: osgeo::proj::io::FactoryException
> SQLite error [ code = 10, msg = disk I/O error ] on SELECT name FROM "geodetic_datum" WHERE auth_name = ? AND code = ?
>
>
> Stack trace
>
> 9  libc++abi.dylib 0x11b80 std::terminate() + 108
>
> 10 proj 0x8270 __clang_call_terminate + 1411 proj 0xad1e8 osgeo::proj::common::IdentifiedObject::_isEquivalentTo(osgeo::proj::common::IdentifiedObject const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 234
> 12 proj 0xe82f4 osgeo::proj::datum::Datum::_isEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 100
> 13 proj 0xed7ac osgeo::proj::datum::GeodeticReferenceFrame::isEquivalentToNoExactTypeCheck(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 96
> 14 proj 0xc0774 osgeo::proj::crs::SingleCRS::baseIsEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 456
> 15 proj 0xc8eb0 osgeo::proj::crs::GeographicCRS::_isEquivalentTo(osgeo::proj::util::IComparable const*, osgeo::proj::util::IComparable::Criterion, std::__1::shared_ptr<osgeo::proj::io::DatabaseContext> const&) const + 172
> 16 proj 0xc627c osgeo::proj::crs::GeodeticCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 724
> 17 proj 0xd072c osgeo::proj::crs::ProjectedCRS::identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 1184
> 18 proj 0xd4028 osgeo::proj::crs::ProjectedCRS::_identify(std::__1::shared_ptr<osgeo::proj::io::AuthorityFactory> const&) const + 44
> ...
>
>
> Are we writing anything to disk at runtime related to sqlite3? Even a
> temporary file? Where?
> If yes, would this problem be fixed if we embed proj.db in the library?
> Currently we are using it as an external file.
>
> My only guess would be that sqlite3 is creating a temporary file in a
> folder with very little space (like /tmp), because the phone should have a
> lot of free space for normal storage.
>
> Thank you
> Javier.
>
> _______________________________________________
> PROJ mailing listPROJ at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260224/ba26e819/attachment.htm>

From gdt at lexort.com  Tue Feb 24 08:55:21 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 24 Feb 2026 11:55:21 -0500
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
In-Reply-To: <38339542-4271-4984-8a12-c22f906a1902@libero.it> (Andrea
 Giudiceandrea via PROJ's message of "Tue, 24 Feb 2026 15:32:08 +0100")
References: <38339542-4271-4984-8a12-c22f906a1902@libero.it>
Message-ID: <rmitsv6rshy.fsf@s1.lexort.com>

Andrea Giudiceandrea via PROJ <proj at lists.osgeo.org> writes:

> Anyway, my concerns and doubts were firstly related to just
> understanding the reason why (although they all use the same PROJ and
> proj.db), cs2cs (and PostGIS and SpatiaLite) uses a particular
> (better) transformation, whereas QGIS another (worst) one, regardless
> of the fact that any of such transformations could be considered the
> right one.
>
> For that transformation, however, all the 5 available Helmert
> operations, the first one of which is used by cs2cs (and PostGIS and
> SpatiaLite), are much better than the ballpark operation used by QGIS
> (which can only choose between the grid shift operation and the
> ballpark one), since the ballpark is more than 100 metres off.

This seems like a good question to me.  I would (without any real
undertanding) expect qgis to offer the same set of pipelines with same
preference.

I've long had a concern that the EPSG database entries may not be
entirely right, and that when people talk about errors, etc., it's
always unclear if they mean the stated error in the EPSG entry, the best
believed error in the literature, or the actual error, compared to
something that is (validly!) believed to be better.  I really don't know
what's up here, but I suspect looking at it all carefully might turn up
some surprises.   If it doesn't, that's great, but it feels like news.

From even.rouault at spatialys.com  Tue Feb 24 09:18:46 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 24 Feb 2026 18:18:46 +0100
Subject: [PROJ] Some (probably dumb) questions about cs2cs and projinfo
In-Reply-To: <rmitsv6rshy.fsf@s1.lexort.com>
References: <38339542-4271-4984-8a12-c22f906a1902@libero.it>
 <rmitsv6rshy.fsf@s1.lexort.com>
Message-ID: <91b4ce81-9427-4bec-8dc0-65ad187429e0@spatialys.com>


Le 24/02/2026 ? 17:55, Greg Troxel via PROJ a ?crit?:
> Andrea Giudiceandrea via PROJ <proj at lists.osgeo.org> writes:
>
>> Anyway, my concerns and doubts were firstly related to just
>> understanding the reason why (although they all use the same PROJ and
>> proj.db), cs2cs (and PostGIS and SpatiaLite) uses a particular
>> (better) transformation, whereas QGIS another (worst) one, regardless
>> of the fact that any of such transformations could be considered the
>> right one.
>>
>> For that transformation, however, all the 5 available Helmert
>> operations, the first one of which is used by cs2cs (and PostGIS and
>> SpatiaLite), are much better than the ballpark operation used by QGIS
>> (which can only choose between the grid shift operation and the
>> ballpark one), since the ballpark is more than 100 metres off.
> This seems like a good question to me.  I would (without any real
> undertanding) expect qgis to offer the same set of pipelines with same
> preference.
>
> I've long had a concern that the EPSG database entries may not be
> entirely right, and that when people talk about errors, etc., it's
> always unclear if they mean the stated error in the EPSG entry, the best
> believed error in the literature, or the actual error, compared to
> something that is (validly!) believed to be better.  I really don't know
> what's up here, but I suspect looking at it all carefully might turn up
> some surprises.   If it doesn't, that's great, but it feels like news.

The database might have errors (anything bigger than one byte has a 
potential for bugs), but I believe most of the practical issues are more 
in the overall consistency, the lack of some recorded transformations, 
and the ambiguities when there are several potential paths. PROJ also 
likely does suboptimal computation of accuracy from individual 
accuracies (but records in the EPSG database don't share the same 
definition of accuracies, depending on how each producer computes it, so 
hard to do much better than the simple addition we d).

I use to say that PROJ CRS to CRS logic is basically a routine engine in 
a graph, with some bits of geodesy to decide if all edges of the graph 
are valid, and the cost they have, and heuristics to cut the 
computations when easy to compute paths have been found. Sometimes your 
GPS makes you try unpredictable roads that are thought to be the best 
ones but are just muddy. PROJ is similar :-)

QGIS could very much change its logic in qgscoordinatetransform_p.cpp 
and qgsdatumtransform.cpp from

 ? ? // We want to check ALL grids, not just those available for use
 ? ? proj_operation_factory_context_set_grid_availability_use( context, 
operationContext, PROJ_GRID_AVAILABILITY_IGNORED );

to doing it once with that parameter and another one 
with??PROJ_GRID_AVAILABILITY_DISCARD_OPERATION_IF_MISSING_GRID (what is 
used in cs2cs) and merge the results to replicate what cs2cs does, while 
still offering the possibility to users to download known locally 
missing grids (what its?PROJ_GRID_AVAILABILITY_IGNORED does). The user 
might get overwhelmed by non relevant paths however.

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From kristian at evers.dev  Wed Feb 25 10:51:31 2026
From: kristian at evers.dev (Kristian Evers)
Date: Wed, 25 Feb 2026 18:51:31 +0000
Subject: [PROJ] PROJ 9.8.0RC2
Message-ID: <E0A35FC0-32D7-40A5-B8C4-93158C14FA32@evers.dev>

A few problems were found in 9.8.0RC1. They should be fixed now and a new release candidate is ready.
Download it here:

https://download.osgeo.org/proj/proj-9.8.0RC2.tar.gz
https://download.osgeo.org/proj/proj-9.8.0RC2.zip

Hopefully there are no further problems with the release candidate but please report them
here or as issues on GitHub if your come across any.

/Kristian


From j1 at jimenezshaw.com  Thu Feb 26 02:29:31 2026
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Thu, 26 Feb 2026 11:29:31 +0100
Subject: [PROJ] Finding not implemented projections
Message-ID: <CADRrdKtO7S5t=OjRzpo7VvzQiiTDxyXzzJSOiuyvHq809Aa-sg@mail.gmail.com>

Hi

Today I met "by accident" EPSG:3053
https://spatialreference.org/ref/epsg/3053/
looking for a westing-northing system.

I realized that the projection "Lambert Conic Conformal (West Orientated)"
is not implemented (all fine, I don't want it to be implemented).

What I want to know is which CRSs from the catalog do not have an
implemented projection, to avoid using them.
We are using "proj_get_crs_info_list_from_database" to get the list of all
the systems (13722). It includes the field "projection_method_name" (a
string).
Is there any function in C or C++ API to know if such a method is
implemented? Doing a quick search in spatialreference I see there are 53
methods in total nowadays.
I don't want to hardcode that list in my code, in case anything changes in
the future.

Thank you.

Cheers
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20260226/f80ce795/attachment-0001.htm>

From gdt at lexort.com  Thu Feb 26 04:45:39 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 26 Feb 2026 07:45:39 -0500
Subject: [PROJ] Finding not implemented projections
In-Reply-To: <CADRrdKtO7S5t=OjRzpo7VvzQiiTDxyXzzJSOiuyvHq809Aa-sg@mail.gmail.com>
 (Javier Jimenez Shaw via PROJ's message of "Thu, 26 Feb 2026 11:29:31
 +0100")
References: <CADRrdKtO7S5t=OjRzpo7VvzQiiTDxyXzzJSOiuyvHq809Aa-sg@mail.gmail.com>
Message-ID: <rmicy1r7jws.fsf@s1.lexort.com>

Javier Jimenez Shaw via PROJ <proj at lists.osgeo.org> writes:

> Today I met "by accident" EPSG:3053
> https://spatialreference.org/ref/epsg/3053/
> looking for a westing-northing system.
>
> I realized that the projection "Lambert Conic Conformal (West Orientated)"
> is not implemented (all fine, I don't want it to be implemented).
>
> What I want to know is which CRSs from the catalog do not have an
> implemented projection, to avoid using them.

Not quite what you asked, but another question is

  which CRSs from the catalog cannot be transformed to [some common
  CRS, perhaps ITRF2020 at its reference epoch]?

and you could perhaps iterate over the list of CRSs and ask for a
pipeline from that to the common CRS, and see which ones lead to an
answer, and which don't.

From even.rouault at spatialys.com  Thu Feb 26 06:34:41 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 26 Feb 2026 15:34:41 +0100
Subject: [PROJ] Finding not implemented projections
In-Reply-To: <CADRrdKtO7S5t=OjRzpo7VvzQiiTDxyXzzJSOiuyvHq809Aa-sg@mail.gmail.com>
References: <CADRrdKtO7S5t=OjRzpo7VvzQiiTDxyXzzJSOiuyvHq809Aa-sg@mail.gmail.com>
Message-ID: <f5ee7ffb-abcf-434d-8d6b-a3dc812615ec@spatialys.com>

Javier,

nothing comes to mind but trying proj_as_proj_string() on them, but that 
will be quite slow if you want to filter the whole list of CRS and do 
that on every CRS. That said, you could pick up one CRS for each of the 
value of?projection_method_name to limit the number of CRS instantiation.

Or add a new C function based on using one of 
osgeo::proj::operation::getMapping()? from 
src/iso19111/operation/parammappings.hpp

Even

Le 26/02/2026 ? 11:29, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> Today I met "by accident" EPSG:3053 
> https://spatialreference.org/ref/epsg/3053/
> looking for a westing-northing system.
>
> I realized that the projection "Lambert Conic Conformal (West 
> Orientated)" is not implemented (all fine, I don't want it to be 
> implemented).
>
> What I want to know is which CRSs from the catalog do not have an 
> implemented projection, to avoid using them.
> We are using "proj_get_crs_info_list_from_database" to get the list of 
> all the systems (13722). It includes the field 
> "projection_method_name" (a string).
> Is there any function in C or C++ API to know if such a method is 
> implemented? Doing a quick search in spatialreference I see there are 
> 53 methods in total nowadays.
> I don't want to hardcode that list in my code, in case anything 
> changes in the future.
>
> Thank you.
>
> Cheers
> Javier.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

-- 
http://www.spatialys.com
My software is free, but my time generally not.