From jukka.rahkonen at maanmittauslaitos.fi Fri Apr 10 06:39:57 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Fri, 10 Apr 2026 13:39:57 +0000 Subject: [MapServer-users] A PROJ_DATA related issue with MS 8.6 Message-ID: Hi, We tried to upgrade into MapServer 8.6 but we had to revert because the GetMap requests begun to fail occasionally. Unfortunately the issue appeared only in the production environment. Now we are a bit lost because in the test environment we do not get errors, and the environment that shows the errors cannot possibly be used for testing. The error appears so that after lots of succesful request lots of subsequent request fail because MapServer can't find PROJ_DATA any more. When we switched into MS 8.6 we also changed the PROJ_DATA configuration into the config file, as ENV block. Before that PROJ_DATA was set in each mapfile separately. Summary about our situation - Production server is a physical RHEL server with 64 cores - Test server is a virtual RHEL server - Both servers were running MapServer 8.6 on same versions of Apache HTTPD mod_fcgid - Every now and then PROJ_DATA got lost on the production server, but never on the test server - PROJ_DATA for MapServer 8.6 was configured in a CONFIG file - layers are mostly raster layers, so GDAL is also involved We plan to test if moving PROJ_DATA configuration back into mapfiles could resolve the issue, but unfortunately the next possibility to make the test is weeks ahead. Meanwhile we would like to know if other users have faced similar issues. Also, if someone has any idea about what goes wrong it could help us to start testing the right things. Judging be the behavior it feels like sometimes a new fast-cgi process does not get the information about the location of the PROJ_DATA directory. But why this would happen only on the procuction server (physical) but not on the test server (virtual) is a mystery. -Jukka Rahkonen- From jmckenna at gatewaygeomatics.com Fri Apr 10 09:04:43 2026 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Fri, 10 Apr 2026 13:04:43 -0300 Subject: [MapServer-users] Fwd: PROJ 9.8.1 is released In-Reply-To: References: Message-ID: <883d9c82-ad37-46da-b887-e61908264eda@gatewaygeomatics.com> Forwarding this important news item to the MapServer community... -------- Forwarded Message -------- 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) From sethg at geographika.co.uk Fri Apr 10 14:47:37 2026 From: sethg at geographika.co.uk (Seth G) Date: Fri, 10 Apr 2026 23:47:37 +0200 Subject: [MapServer-users] A PROJ_DATA related issue with MS 8.6 In-Reply-To: References: Message-ID: <9974c80a-5a5e-4ef6-bf85-3ee058ed2324@app.fastmail.com> Hi Jukka, I've not encountered this before, but this could be due to your production server having a lot of traffic (which any test server would not). Switching to using PROJ_DATA in your Mapfiles would likely fix it, as the value would be read on every request. A few theories on a possible clause below. 1. The FastCGI worker crashes, and msCleanUp() is called. This calls msSetPROJ_DATA(NULL, NULL) and msProjectionContextPoolCleanup(), and the worker handles some other requests before being recycled. 2. There is some race condition, where msLoadConfig is using putenv and PROJ is calling getenv before the value is set. The value (NULL) is then cached. https://github.com/OSGeo/PROJ/blob/79e50ef64fd72563e563452900e3e838932a6dec/src/filemanager.cpp#L1113 There is a note in https://github.com/toshic/libfcgi/blob/master/libfcgi/fcgi_stdio.c > In particular do not use setenv(3) or putenv(3) in conjunction with FCGI_Accept. Maybe setting up the PROJ context outside the FCGI_Accept() would help here. 3. msProjDataInitFromEnv() (which calls msSetPROJ_DATA) is called in msSetUp() and in msLoadConfig() (via msConfigSetConfigOption). 4. Something about the PROJ connection pools and msProjectionContextGetFromPool.. All the above have the same root issue - getenv returns a NULL for PROJ_DATA, either because putenv hasn't yet been called, or it has been set to NULL. Maybe adding logging in some of the above functions would help to find the cause. Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Fri, Apr 10, 2026, at 3:39 PM, Rahkonen Jukka via MapServer-users wrote: > Hi, > > We tried to upgrade into MapServer 8.6 but we had to revert because the > GetMap requests begun to fail occasionally. Unfortunately the issue > appeared only in the production environment. Now we are a bit lost > because in the test environment we do not get errors, and the > environment that shows the errors cannot possibly be used for testing. > > The error appears so that after lots of succesful request lots of > subsequent request fail because MapServer can't find PROJ_DATA any more. > When we switched into MS 8.6 we also changed the PROJ_DATA > configuration into the config file, as ENV block. Before that > PROJ_DATA was set in each mapfile separately. > > Summary about our situation > > - Production server is a physical RHEL server with 64 cores > - Test server is a virtual RHEL server > - Both servers were running MapServer 8.6 on same versions of Apache > HTTPD mod_fcgid > - Every now and then PROJ_DATA got lost on the production server, but > never on the test server > - PROJ_DATA for MapServer 8.6 was configured in a CONFIG file > - layers are mostly raster layers, so GDAL is also involved > > We plan to test if moving PROJ_DATA configuration back into mapfiles > could resolve the issue, but unfortunately the next possibility to make > the test is weeks ahead. Meanwhile we would like to know if other users > have faced similar issues. Also, if someone has any idea about what > goes wrong it could help us to start testing the right things. Judging > be the behavior it feels like sometimes a new fast-cgi process does not > get the information about the location of the PROJ_DATA directory. But > why this would happen only on the procuction server (physical) but not > on the test server (virtual) is a mystery. > > -Jukka Rahkonen- > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users