<div dir="auto"><div>🚀 Alan</div><div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2026, 7:12 AM Even Rouault via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
Download the archives here:<br>
<br>
<a href="https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz" rel="noreferrer noreferrer" target="_blank">https://download.osgeo.org/proj/proj-9.8.1RC1.tar.gz</a><br>
<a href="https://download.osgeo.org/proj/proj-9.8.1RC1.zip" rel="noreferrer noreferrer" target="_blank">https://download.osgeo.org/proj/proj-9.8.1RC1.zip</a><br>
<br>
Community members, please report any issue.<br>
PSC members, please test and cast your vote to promote it to final 9.8.1<br>
<br>
Starting with my +1<br>
<br>
Even<br>
<br>
## 9.8.1<br>
<br>
### Warning<br>
<br>
It was discovered after the PROJ 9.8.0 release that several EPSG updates <br>
introduced<br>
after EPSG v12.033 - notably the introduction of national realizations <br>
of ETRS89<br>
(ETRS89-XXX […] where XXX is the 3-letter ISO country code) - caused <br>
backward<br>
incompatibilities in some workflows involving the ETRS89 CRS.<br>
<br>
In particular, transformations between ETRS89 and national CRSs based on <br>
other<br>
datums are known to be affected for Austria, Belgium, Catalonia, the <br>
Netherlands,<br>
Romania, and Serbia. See #4736 for more details.<br>
<br>
While we intend to resume tracking the latest EPSG releases in future PROJ<br>
versions, the safest solution identified so far to address these <br>
regressions is to<br>
**revert the EPSG related content of its database from EPSG v12.049 to <br>
v12.029**,<br>
where v12.029 was the version distributed with PROJ 9.7.1<br>
<br>
As a consequence of this revert, the EPSG datum and CRS records <br>
introduced in<br>
PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and <br>
CRS, are no<br>
longer available in PROJ 9.8.1.<br>
<br>
### Updates<br>
<br>
* Database: **Revert content from EPSG v12.049 to v12.029** (#4741).<br>
   See above warning for more details.<br>
<br>
* CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694)<br>
<br>
### Bug Fixes<br>
<br>
* Make sure that epoch is set in more scenarios of time-dependent <br>
transformations (#4688)<br>
<br>
* pj_obj_create: use database context if already open for grid name <br>
resolution (#4703)<br>
<br>
* Chain vertical CRS transformations through intermediate same-datum <br>
vertical CRS (#4711)<br>
   Helps for example for **EPSG:5705** (Baltic 1977 height) to <br>
**EPSG:5706** (Caspian depth)<br>
   by using intermediate operation from Baltic 1977 height to Caspian <br>
*height*<br>
<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank" rel="noreferrer">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>