[PROJ] PROJ 9.8.1 release candidate and motion to approve it

[Kristian Evers]

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 <proj at lists.osgeo.org> wrote:

> 🚀 Alan
>
> On Wed, Apr 8, 2026, 7:12 AM Even Rouault via PROJ <proj at lists.osgeo.org> 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: <http://lists.osgeo.org/pipermail/proj/attachments/20260409/ab99b0b6/attachment.htm>