From even.rouault at spatialys.com Sun Apr 5 09:53:01 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 5 Apr 2026 18:53:01 +0200 Subject: [PROJ] ETRS89 issues with PROJ 9.8.0 Message-ID: <5d59f01f-7ef8-45c0-bd48-62e911562c6f@spatialys.com> Hi, We're hearing alarm bells coming from various European users related to transformations between pre-ETRS89 national CRS an ETRS89-based CRS,? caused by significant changes in that area that have been introduced in the EPSG dataset embedded in PROJ 9.8.0. Namely the creation of ETRS89-XXX datums where XXX is the ISO code of the country. https://github.com/OSGeo/PROJ/pull/4736 exposes a few of the issues met, an a partial workaround, but not covering all cases. Please also report issues you might hit in that area. We are working with EPSG to help fix the situation. For people mastering their supply chain, reverting back to 9.7.1 might be prudent. Even -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Wed Apr 8 05:12:03 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 8 Apr 2026 14:12:03 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it Message-ID: Hi, I've prepared a release candidate for PROJ 9.8.1, ahead of the planned schedule, to address the ETRS89 related issues mentioned in the below release notes. Download the archives here: https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz https://download.osgeo.org/proj/proj-9.8.1RC1.zip Community members, please report any issue. PSC members, please test and cast your vote to promote it to final 9.8.1 Starting with my +1 Even ## 9.8.1 ### Warning It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced after EPSG v12.033 - notably the introduction of national realizations of ETRS89 (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused backward incompatibilities in some workflows involving the ETRS89 CRS. In particular, transformations between ETRS89 and national CRSs based on other datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, Romania, and Serbia. See #4736 for more details. While we intend to resume tracking the latest EPSG releases in future PROJ versions, the safest solution identified so far to address these regressions is to **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, where v12.029 was the version distributed with PROJ 9.7.1 As a consequence of this revert, the EPSG datum and CRS records introduced in PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no longer available in PROJ 9.8.1. ### Updates * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). ? See above warning for more details. * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) ### Bug Fixes * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) * pj_obj_create: use database context if already open for grid name resolution (#4703) * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) ? Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) ? by using intermediate operation from Baltic 1977 height to Caspian *height* -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Wed Apr 8 15:23:38 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 9 Apr 2026 00:23:38 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: Hi to facilitate the testing for some people that just want to check if "their transformation works", I created this repository https://jjimenezshaw.github.io/wasm-proj-release-candidate/transform.html It changed the colours and added a header to make it clear that it is not its "parent" page, but just something to test the release candidate. It will disappear afterwards. If you want to compare with 9.8.0, go to https://jjimenezshaw.github.io/wasm-proj I hope it helps. Cheers Javier. On Wed, 8 Apr 2026 at 14:12, Even Rouault via PROJ wrote: > Hi, > > I've prepared a release candidate for PROJ 9.8.1, ahead of the planned > schedule, to address the ETRS89 related issues mentioned in the below > release notes. > > Download the archives here: > > https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz > https://download.osgeo.org/proj/proj-9.8.1RC1.zip > > Community members, please report any issue. > PSC members, please test and cast your vote to promote it to final 9.8.1 > > Starting with my +1 > > Even > > ## 9.8.1 > > ### Warning > > It was discovered after the PROJ 9.8.0 release that several EPSG updates > introduced > after EPSG v12.033 - notably the introduction of national realizations > of ETRS89 > (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused > backward > incompatibilities in some workflows involving the ETRS89 CRS. > > In particular, transformations between ETRS89 and national CRSs based on > other > datums are known to be affected for Austria, Belgium, Catalonia, the > Netherlands, > Romania, and Serbia. See #4736 for more details. > > While we intend to resume tracking the latest EPSG releases in future PROJ > versions, the safest solution identified so far to address these > regressions is to > **revert the EPSG related content of its database from EPSG v12.049 to > v12.029**, > where v12.029 was the version distributed with PROJ 9.7.1 > > As a consequence of this revert, the EPSG datum and CRS records > introduced in > PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and > CRS, are no > longer available in PROJ 9.8.1. > > ### Updates > > * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). > See above warning for more details. > > * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) > > ### Bug Fixes > > * Make sure that epoch is set in more scenarios of time-dependent > transformations (#4688) > > * pj_obj_create: use database context if already open for grid name > resolution (#4703) > > * Chain vertical CRS transformations through intermediate same-datum > vertical CRS (#4711) > Helps for example for **EPSG:5705** (Baltic 1977 height) to > **EPSG:5706** (Caspian depth) > by using intermediate operation from Baltic 1977 height to Caspian > *height* > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alansnow21 at gmail.com Wed Apr 8 18:15:54 2026 From: alansnow21 at gmail.com (Alan Snow) Date: Wed, 8 Apr 2026 20:15:54 -0500 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: ? Alan On Wed, Apr 8, 2026, 7:12?AM Even Rouault via PROJ wrote: > Hi, > > I've prepared a release candidate for PROJ 9.8.1, ahead of the planned > schedule, to address the ETRS89 related issues mentioned in the below > release notes. > > Download the archives here: > > https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz > https://download.osgeo.org/proj/proj-9.8.1RC1.zip > > Community members, please report any issue. > PSC members, please test and cast your vote to promote it to final 9.8.1 > > Starting with my +1 > > Even > > ## 9.8.1 > > ### Warning > > It was discovered after the PROJ 9.8.0 release that several EPSG updates > introduced > after EPSG v12.033 - notably the introduction of national realizations > of ETRS89 > (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused > backward > incompatibilities in some workflows involving the ETRS89 CRS. > > In particular, transformations between ETRS89 and national CRSs based on > other > datums are known to be affected for Austria, Belgium, Catalonia, the > Netherlands, > Romania, and Serbia. See #4736 for more details. > > While we intend to resume tracking the latest EPSG releases in future PROJ > versions, the safest solution identified so far to address these > regressions is to > **revert the EPSG related content of its database from EPSG v12.049 to > v12.029**, > where v12.029 was the version distributed with PROJ 9.7.1 > > As a consequence of this revert, the EPSG datum and CRS records > introduced in > PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and > CRS, are no > longer available in PROJ 9.8.1. > > ### Updates > > * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). > See above warning for more details. > > * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) > > ### Bug Fixes > > * Make sure that epoch is set in more scenarios of time-dependent > transformations (#4688) > > * pj_obj_create: use database context if already open for grid name > resolution (#4703) > > * Chain vertical CRS transformations through intermediate same-datum > vertical CRS (#4711) > Helps for example for **EPSG:5705** (Baltic 1977 height) to > **EPSG:5706** (Caspian depth) > by using intermediate operation from Baltic 1977 height to Caspian > *height* > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian at evers.dev Thu Apr 9 04:06:19 2026 From: kristian at evers.dev (Kristian Evers) Date: Thu, 09 Apr 2026 11:06:19 +0000 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: Even, It is a +1 from me as is, but I would suggest that the fix to gie in https://github.com/OSGeo/PROJ/pull/4744 is included in the final release. The reason being that it will provide the means for geodetic authorities to supply test material that can be useful when validating the ETRS89 changes. I'd like to start mobilizing people in the not too distant future in an effort to procure better test data to optimize chances of discovering issues like the ETRS89-xxx problem before a release. The fix to the gie app is rather localized so I regard it as a low risk to include it without a second release candidate. /Kristian On Thursday, April 9th, 2026 at 03:16, Alan Snow via PROJ wrote: > ? Alan > > On Wed, Apr 8, 2026, 7:12?AM Even Rouault via PROJ wrote: > >> Hi, >> >> I've prepared a release candidate for PROJ 9.8.1, ahead of the planned schedule, to address the ETRS89 related issues mentioned in the below release notes. >> >> Download the archives here: >> >> https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz >> https://download.osgeo.org/proj/proj-9.8.1RC1.zip >> >> Community members, please report any issue. >> PSC members, please test and cast your vote to promote it to final 9.8.1 >> >> Starting with my +1 >> >> Even >> >> ## 9.8.1 >> >> ### Warning >> >> It was discovered after the PROJ 9.8.0 release that several EPSG updates >> introduced >> after EPSG v12.033 - notably the introduction of national realizations >> of ETRS89 >> (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused >> backward >> incompatibilities in some workflows involving the ETRS89 CRS. >> >> In particular, transformations between ETRS89 and national CRSs based on >> other >> datums are known to be affected for Austria, Belgium, Catalonia, the >> Netherlands, >> Romania, and Serbia. See #4736 for more details. >> >> While we intend to resume tracking the latest EPSG releases in future PROJ >> versions, the safest solution identified so far to address these >> regressions is to >> **revert the EPSG related content of its database from EPSG v12.049 to >> v12.029**, >> where v12.029 was the version distributed with PROJ 9.7.1 >> >> As a consequence of this revert, the EPSG datum and CRS records >> introduced in >> PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and >> CRS, are no >> longer available in PROJ 9.8.1. >> >> ### Updates >> >> * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). >> See above warning for more details. >> >> * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) >> >> ### Bug Fixes >> >> * Make sure that epoch is set in more scenarios of time-dependent >> transformations (#4688) >> >> * pj_obj_create: use database context if already open for grid name >> resolution (#4703) >> >> * Chain vertical CRS transformations through intermediate same-datum >> vertical CRS (#4711) >> Helps for example for **EPSG:5705** (Baltic 1977 height) to >> **EPSG:5706** (Caspian depth) >> by using intermediate operation from Baltic 1977 height to Caspian >> *height* >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From karney at alum.mit.edu Thu Apr 9 04:11:40 2026 From: karney at alum.mit.edu (Charles Karney) Date: Thu, 9 Apr 2026 11:11:40 +0000 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: +1 Charles > On Apr 8, 2026, at 08:12, Even Rouault via PROJ wrote: > > Hi, > > I've prepared a release candidate for PROJ 9.8.1, ahead of the planned schedule, to address the ETRS89 related issues mentioned in the below release notes. > > Download the archives here: > > https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz > https://download.osgeo.org/proj/proj-9.8.1RC1.zip > > Community members, please report any issue. > PSC members, please test and cast your vote to promote it to final 9.8.1 > > Starting with my +1 > > Even > > ## 9.8.1 > > ### Warning > > It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced > after EPSG v12.033 - notably the introduction of national realizations of ETRS89 > (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused backward > incompatibilities in some workflows involving the ETRS89 CRS. > > In particular, transformations between ETRS89 and national CRSs based on other > datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, > Romania, and Serbia. See #4736 for more details. > > While we intend to resume tracking the latest EPSG releases in future PROJ > versions, the safest solution identified so far to address these regressions is to > **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, > where v12.029 was the version distributed with PROJ 9.7.1 > > As a consequence of this revert, the EPSG datum and CRS records introduced in > PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no > longer available in PROJ 9.8.1. > > ### Updates > > * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). > See above warning for more details. > > * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) > > ### Bug Fixes > > * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) > > * pj_obj_create: use database context if already open for grid name resolution (#4703) > > * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) > Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) > by using intermediate operation from Baltic 1977 height to Caspian *height* > > > -- > 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 From even.rouault at spatialys.com Thu Apr 9 04:17:51 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 9 Apr 2026 13:17:51 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: <26cc70aa-d059-470a-8188-f2eb74b2f4bc@spatialys.com> > > I would suggest that the fix to gie in > https://github.com/OSGeo/PROJ/pull/4744?is included in the final > release. The reason being that it will provide the means for geodetic > authorities to supply test material that can be useful when validating > the ETRS89 changes. I'd like to start mobilizing people in the not too > distant future in an effort to procure better test data to optimize > chances of discovering issues like the ETRS89-xxx problem before a > release. 'k, backported in the 9.8 branch (https://github.com/OSGeo/PROJ/commit/fd6e4320e2576534e0a9eb83cfc2d26c6acff60a). Will cut the final release from that -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard at hobu.co Thu Apr 9 04:49:06 2026 From: howard at hobu.co (Howard Butler) Date: Thu, 9 Apr 2026 06:49:06 -0500 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: > On Apr 8, 2026, at 7:12?AM, Even Rouault via PROJ wrote: > > Starting with my +1 +1 Howard Should PROJ consider implementing some kind of lag in its uptake of EPSG databases? Maybe it wouldn't have mattered in this case, however. "A lot of luck to whoever want to put together the computational part of the datum shift software." ? Gerry Eveneden [1] [1] https://howardbutler.com/files/history-of-proj4-foss4g2017-howard-butler.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian at evers.dev Thu Apr 9 05:12:11 2026 From: kristian at evers.dev (Kristian Evers) Date: Thu, 09 Apr 2026 12:12:11 +0000 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: <4NG4n96N09feu36yXEh41RqCxO1BlYtd-girfuIQiIV_HaEkRZCnTCV4ax960W9b3ajaGnXHfecQunx2kEZYtku-kIHKM9VljK48P3aF72Q=@evers.dev> Howard, I don't think we will gain anything by lagging behind by x months of EPSG releases. No one else is testing their releases in real time (as far as I know), so we would just find the same issues at a later date. I think our best chance for now is to improve testing on our side as much as possible, as well as providing the means for non-techy geodesist to tests stuff in development. The first part I think we can start acting on right away, and perhaps even coordinate with the EPSG folks somehow. The second part would require pre-release binaries to be easy to access, as I don't think we can expect that geodesy experts are able to compile PROJ from source. This meshes well with previous talks on automating the release process. /Kristian On Thursday, April 9th, 2026 at 13:49, Howard Butler via PROJ wrote: >> On Apr 8, 2026, at 7:12?AM, Even Rouault via PROJ wrote: >> >> Starting with my +1 > > +1 Howard > > Should PROJ consider implementing some kind of lag in its uptake of EPSG databases? Maybe it wouldn't have mattered in this case, however. > "A lot of luck to whoever want to put together the computational part of the datum shift software." ? Gerry Eveneden [1] > > [1] https://howardbutler.com/files/history-of-proj4-foss4g2017-howard-butler.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Apr 9 05:27:35 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 9 Apr 2026 14:27:35 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: <4NG4n96N09feu36yXEh41RqCxO1BlYtd-girfuIQiIV_HaEkRZCnTCV4ax960W9b3ajaGnXHfecQunx2kEZYtku-kIHKM9VljK48P3aF72Q=@evers.dev> References: <4NG4n96N09feu36yXEh41RqCxO1BlYtd-girfuIQiIV_HaEkRZCnTCV4ax960W9b3ajaGnXHfecQunx2kEZYtku-kIHKM9VljK48P3aF72Q=@evers.dev> Message-ID: > > ?The second part would require pre-release binaries to be easy to > access, as I don't think we can expect that geodesy experts are able > to compile PROJ from source. This meshes well with previous talks on > automating the release process. Javier's WASM + JS / HTML builds are also a very user-friendly way in running transformations in your browser. If we have a HTML page available and refreshed with them at every push into PROJ master, there's no excuse for anyone not being able to test, at any time, not just at release time. -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Thu Apr 9 06:08:05 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Thu, 9 Apr 2026 15:08:05 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: +1 Javier On Thu, 9 Apr 2026 at 13:11, Charles Karney via PROJ wrote: > +1 Charles > > > > On Apr 8, 2026, at 08:12, Even Rouault via PROJ > wrote: > > > > Hi, > > > > I've prepared a release candidate for PROJ 9.8.1, ahead of the planned > schedule, to address the ETRS89 related issues mentioned in the below > release notes. > > > > Download the archives here: > > > > https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz > > https://download.osgeo.org/proj/proj-9.8.1RC1.zip > > > > Community members, please report any issue. > > PSC members, please test and cast your vote to promote it to final 9.8.1 > > > > Starting with my +1 > > > > Even > > > > ## 9.8.1 > > > > ### Warning > > > > It was discovered after the PROJ 9.8.0 release that several EPSG updates > introduced > > after EPSG v12.033 - notably the introduction of national realizations > of ETRS89 > > (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused > backward > > incompatibilities in some workflows involving the ETRS89 CRS. > > > > In particular, transformations between ETRS89 and national CRSs based on > other > > datums are known to be affected for Austria, Belgium, Catalonia, the > Netherlands, > > Romania, and Serbia. See #4736 for more details. > > > > While we intend to resume tracking the latest EPSG releases in future > PROJ > > versions, the safest solution identified so far to address these > regressions is to > > **revert the EPSG related content of its database from EPSG v12.049 to > v12.029**, > > where v12.029 was the version distributed with PROJ 9.7.1 > > > > As a consequence of this revert, the EPSG datum and CRS records > introduced in > > PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and > CRS, are no > > longer available in PROJ 9.8.1. > > > > ### Updates > > > > * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). > > See above warning for more details. > > > > * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) > > > > ### Bug Fixes > > > > * Make sure that epoch is set in more scenarios of time-dependent > transformations (#4688) > > > > * pj_obj_create: use database context if already open for grid name > resolution (#4703) > > > > * Chain vertical CRS transformations through intermediate same-datum > vertical CRS (#4711) > > Helps for example for **EPSG:5705** (Baltic 1977 height) to > **EPSG:5706** (Caspian depth) > > by using intermediate operation from Baltic 1977 height to Caspian > *height* > > > > > > -- > > 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 > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.simon at spw.wallonie.be Thu Apr 9 07:48:46 2026 From: nicolas.simon at spw.wallonie.be (SIMON Nicolas) Date: Thu, 9 Apr 2026 14:48:46 +0000 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: Hi +1 Nicolas, from/for Belgium As Even mentioned in https://github.com/OSGeo/PROJ/pull/4736, the changes proposed by EPSG raised a red flag. Thanks for this new release. Nicolas -----Message d'origine----- De : PROJ De la part de Even Rouault via PROJ Envoy? : mercredi 8 avril 2026 14:12 ? : proj Objet : [PROJ] PROJ 9.8.1 release candidate and motion to approve it Hi, I've prepared a release candidate for PROJ 9.8.1, ahead of the planned schedule, to address the ETRS89 related issues mentioned in the below release notes. Download the archives here: https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz https://download.osgeo.org/proj/proj-9.8.1RC1.zip Community members, please report any issue. PSC members, please test and cast your vote to promote it to final 9.8.1 Starting with my +1 Even ## 9.8.1 ### Warning It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced after EPSG v12.033 - notably the introduction of national realizations of ETRS89 (ETRS89-XXX [...] where XXX is the 3-letter ISO country code) - caused backward incompatibilities in some workflows involving the ETRS89 CRS. In particular, transformations between ETRS89 and national CRSs based on other datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, Romania, and Serbia. See #4736 for more details. While we intend to resume tracking the latest EPSG releases in future PROJ versions, the safest solution identified so far to address these regressions is to **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, where v12.029 was the version distributed with PROJ 9.7.1 As a consequence of this revert, the EPSG datum and CRS records introduced in PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no longer available in PROJ 9.8.1. ### Updates * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). See above warning for more details. * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) ### Bug Fixes * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) * pj_obj_create: use database context if already open for grid name resolution (#4703) * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) by using intermediate operation from Baltic 1977 height to Caspian *height* -- 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 From even.rouault at spatialys.com Fri Apr 10 05:43:48 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 10 Apr 2026 14:43:48 +0200 Subject: [PROJ] PROJ 9.8.1 release candidate and motion to approve it In-Reply-To: References: Message-ID: <8311f0ae-7666-446c-bb4c-2a2df0304ba2@spatialys.com> Motion passed with +1 from PSC members AlanS, KristianE, CharlesK, JavierJS, HowardB and myself. Release announcement to come soon Le 08/04/2026 ? 14:12, Even Rouault via PROJ a ?crit?: > Hi, > > I've prepared a release candidate for PROJ 9.8.1, ahead of the planned > schedule, to address the ETRS89 related issues mentioned in the below > release notes. > > Download the archives here: > > https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz > https://download.osgeo.org/proj/proj-9.8.1RC1.zip > > Community members, please report any issue. > PSC members, please test and cast your vote to promote it to final 9.8.1 > > Starting with my +1 > > Even > > ## 9.8.1 > > ### Warning > > It was discovered after the PROJ 9.8.0 release that several EPSG > updates introduced > after EPSG v12.033 - notably the introduction of national realizations > of ETRS89 > (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused > backward > incompatibilities in some workflows involving the ETRS89 CRS. > > In particular, transformations between ETRS89 and national CRSs based > on other > datums are known to be affected for Austria, Belgium, Catalonia, the > Netherlands, > Romania, and Serbia. See #4736 for more details. > > While we intend to resume tracking the latest EPSG releases in future > PROJ > versions, the safest solution identified so far to address these > regressions is to > **revert the EPSG related content of its database from EPSG v12.049 to > v12.029**, > where v12.029 was the version distributed with PROJ 9.7.1 > > As a consequence of this revert, the EPSG datum and CRS records > introduced in > PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and > CRS, are no > longer available in PROJ 9.8.1. > > ### Updates > > * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). > ? See above warning for more details. > > * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) > > ### Bug Fixes > > * Make sure that epoch is set in more scenarios of time-dependent > transformations (#4688) > > * pj_obj_create: use database context if already open for grid name > resolution (#4703) > > * Chain vertical CRS transformations through intermediate same-datum > vertical CRS (#4711) > ? Helps for example for **EPSG:5705** (Baltic 1977 height) to > **EPSG:5706** (Caspian depth) > ? by using intermediate operation from Baltic 1977 height to Caspian > *height* > > -- http://www.spatialys.com My software is free, but my time generally not. From even.rouault at spatialys.com Fri Apr 10 06:12:16 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 10 Apr 2026 15:12:16 +0200 Subject: [PROJ] PROJ 9.8.1 is released Message-ID: It?s my pleasure to announce the release of PROJ 9.8.1! The release includes a few updates, bug fixes and a major regression fix for ETRS89-related coordinates operations. See the release notes below. Download the archives here: https://download.osgeo.org/proj/proj-9.8.1.tar.gz https://download.osgeo.org/proj/proj-9.8.1.zip /Even ## 9.8.1 ### Warning It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced after EPSG v12.033 - notably the introduction of national realizations of ETRS89 (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused backward incompatibilities in some workflows involving the ETRS89 CRS. In particular, transformations between ETRS89 and national CRSs based on other datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, Romania, and Serbia. See #4736 for more details. While we intend to resume tracking the latest EPSG releases in future PROJ versions, the safest solution identified so far to address these regressions is to **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, where v12.029 was the version distributed with PROJ 9.7.1 As a consequence of this revert, the EPSG datum and CRS records introduced in PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no longer available in PROJ 9.8.1. ### Updates * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). ? See above warning for more details. * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) ### Bug Fixes * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) * pj_obj_create: use database context if already open for grid name resolution (#4703) * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) ? Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) ? by using intermediate operation from Baltic 1977 height to Caspian *height* * gie: various fixes around crs_src/crs_dst support and bootstrap ? test/gie/epsg_grid.gie and test/gie/epsg_no_grid.gie (#4740) -- http://www.spatialys.com My software is free, but my time generally not. From j1 at jimenezshaw.com Tue Apr 14 10:30:31 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Tue, 14 Apr 2026 19:30:31 +0200 Subject: [PROJ] Thoughts after PROJ 9.8.1 Message-ID: Hi all The last couple of weeks were definitely different than the normal and quiet life in PROJ. As most of you already know, PROJ 9.8.0 was released on March 2nd with the latest version of EPSG, as usual. But days and weeks later we had some complains that some transformations from CRS to CRS were not returning the expected results. The reason was not a change in PROJ code itself, but an update from EPSG. Big changes involving the datum ensemble ETRS89 in Europe. Some people started complaining. People I have never seen active in the mailing list. Suddenly, a quiet project became a big problem. Products were going backwards to the previous version, 9.7.1, to avoid this problematic release. PROJ was mentioned more than I have seen in previous years. Wow, PROJ was important, but nobody was saying it when it was working! Since we realized that the problem was not punctual but was affecting several countries in Europe we decided that a quick bugfix release 9.8.1 was needed. In less than a week (including the Easter holidays) PROJ had a release candidate that everybody could test (did they?). I want to thank Even Rouault and Kristian Evers for their work to have ready that release. In one week! I don't see other organizations or companies reacting that fast (I will not mention any name). Reverting those changes were not that easy. In PROJ we already realized that we need other type of unit tests, that involve the geodetic agencies. We are working on it. Maybe PROJ's users -direct and indirect- should think how they can help or contribute. For instance sponsoring (via GDAL Sponsorship program) https://proj.org/en/stable/users.html#sponsors I hope the geodetic agencies get involved to develop those unit tests (that will check both PROJ and EPSG changes ;) It is in the human nature to accept as normal things that work, and only point them when they fail. These episodes help us to see that some important things are not noticed, but they are still needed. We should care them just a bit more. Cheers Javier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j1 at jimenezshaw.com Wed Apr 15 11:15:43 2026 From: j1 at jimenezshaw.com (Javier Jimenez Shaw) Date: Wed, 15 Apr 2026 20:15:43 +0200 Subject: [PROJ] More about transformations web wasm-proj Message-ID: Hi all I have been improving the webpage to perform coordinate transformations with PROJ https://jjimenezshaw.github.io/wasm-proj/ One of the improvements is the usage of your own proj.db or auxiliary databases. As you may remember last year I made an auxiliary database for PROJ with the beta data published in June 2025 for the modernized NSRS in USA (NATRF2022 and friends) https://github.com/jjimenezshaw/NSRS-2022-PROJ You can combine both things to directly run transformations with the modernized NSRS. To avoid the work of downloading the file nsrs_proj.db, it can be specified in the URL with this extra option: https://jjimenezshaw.github.io/wasm-proj/transform.html?nsrs_aux_db=1 That loads automatically the auxiliary database mentioned above. Easy! In this link you can see how both the vertical and horizontal coordinates are transformed. https://jjimenezshaw.github.io/wasm-proj/transform.html?nsrs_aux_db=1&st=combo&tt=combo&sh=EPSG%3A9989&th=NSRS%3ANATRF2022_2D&tv=NSRS%3ANAPGD2022&p3d=1&net=1&coords=35+-100+0+2026.3 There is also a new section to compute "Distortion Factors". Probably too niche, but I had fun doing it. Enjoy it. (Have you seen the section "Last Operation Summary" at the bottom of the transformer? It is useful to understand what happened exactly) No trackers, no ads, no monitoring of user activity. Open Source. Best regards, Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick_mein at trimble.com Wed Apr 15 17:20:14 2026 From: nick_mein at trimble.com (Nick Mein) Date: Thu, 16 Apr 2026 12:20:14 +1200 Subject: [PROJ] More about transformations web wasm-proj In-Reply-To: References: Message-ID: Hey Javier, I was really pleased to discover wasm-proj last week! I'd actually been looking for something exactly like that the week before. My use-case is comparing the results produced by Proj with those produced by our own internal library. I'm pleased to report that (given a sample of one point in one CRS :-) they match exactly. Best regards, Nick. On Thu, 16 Apr 2026 at 06:16, Javier Jimenez Shaw via PROJ < proj at lists.osgeo.org> wrote: > Hi all > > I have been improving the webpage to perform coordinate transformations > with PROJ > https://jjimenezshaw.github.io/wasm-proj/ > > One of the improvements is the usage of your own proj.db or auxiliary > databases. > > As you may remember last year I made an auxiliary database for PROJ with > the beta data published in June 2025 for the modernized NSRS in USA > (NATRF2022 and friends) > https://github.com/jjimenezshaw/NSRS-2022-PROJ > > You can combine both things to directly run transformations with the > modernized NSRS. > To avoid the work of downloading the file nsrs_proj.db, it can be > specified in the URL with this extra option: > https://jjimenezshaw.github.io/wasm-proj/transform.html?nsrs_aux_db=1 > > That loads automatically the auxiliary database mentioned above. Easy! > > In this link you can see how both the vertical and horizontal coordinates > are transformed. > > https://jjimenezshaw.github.io/wasm-proj/transform.html?nsrs_aux_db=1&st=combo&tt=combo&sh=EPSG%3A9989&th=NSRS%3ANATRF2022_2D&tv=NSRS%3ANAPGD2022&p3d=1&net=1&coords=35+-100+0+2026.3 > > There is also a new section to compute "Distortion Factors". Probably too > niche, but I had fun doing it. Enjoy it. > > (Have you seen the section "Last Operation Summary" at the bottom of the > transformer? It is useful to understand what happened exactly) > > No trackers, no ads, no monitoring of user activity. Open Source. > > Best regards, > Javier > > > > _______________________________________________ > PROJ mailing list > PROJ at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/proj > -------------- next part -------------- An HTML attachment was scrubbed... URL: