I think we have several possibilities: environment var (system
variable), web server environment variable (Apache config), MapServer
.conf, and local mapfile setting.
I would say that the local mapfile should always be used first by
MapServer, in this order:
- check mapfile setting,
- if not found, check for MapServer .conf setting,
- if not found, check for web server setting
- if not found, check for system environment variable
- ...else, battle for superiority with the other PROJ_LIB settings by
the other FOSS4G software on that container
Notes:
- this shared PROJ_LIB issue is not just for MapServer, but is faced by
all FOSS4G projects that share this variable. On Windows servers now it
is common for me to have several PROJ_LIB settings, one for each FOSS4G
software that depends on (depends on that PROJ version for that
software), such as QGIS, GDAL, MapServer, etc. etc. Meaning: f you need
a job run for one software, enable that specific PROJ_LIB.
It's fun :)
-jeff
On 2022-07-06 5:49 p.m., Steve Lime wrote:
This could/would have been the case in past versions as well, right? So
I don't think this is a new issue. IMHO I'd think central config
settings should trump local settings for something like this.
On Wed, Jul 6, 2022 at 2:40 PM Seth G <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
Using MapServer 8.0 beta and FastCGI (on Windows) I'm running into
an issue where the PROJ_LIB setting is sometimes set by the value in
the CONFIG file and sometimes by the setting in the Mapfile:
CONFIG
ENV
MS_MAP_PATTERN "."
PROJ_LIB "C:/MapServer/bin/proj7/share" #proj7
END
END
Then in a Mapfile:
CONFIG "PROJ_LIB" "C:/MapServer/bin/proj/SHARE" # uses proj6
Requests will use one PROJ setting then switch to another seemingly
at random.
Should one always take precedence over the other?
Seth
--
web:https://geographika.net <https://geographika.net>
twitter: @geographika
_______________________________________________
MapServer-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-dev