Ok thanks Steve, but can you be more specific regarding 'local setting'? On Windows each FOSS4G software has its own PROJ instance/version and its own PROJ_LIB variable (yes it's complete disaster, waiting to happen). So where does the mapfile's PROJ_LIB setting, and then the System environment variable fit into your 3 ?

Thanks,

-jeff



On 2022-07-06 6:44 p.m., Steve Lime wrote:
I understand your logic and would agree for most things. However, one benefit of the config file is to allow admins to lock things down - especially items like environment variable settings that tell MapServer to load code. Hence my original response, so 1) config file, 2) web server environment, 3) local setting.

--Steve

On Wed, Jul 6, 2022 at 4:05 PM Jeff McKenna <[email protected] <mailto:[email protected]>> wrote:

    Oh don't forget PostGIS' use of that same variable (that's where I hit
    this on servers constantly).

    So, my point is, that the only way we can avoid all this "environment"
    variable chaos is first always use the local mapfile setting, then look
    for .conf, and if neither has this, check the other sources.

    -jeff



    On 2022-07-06 6:01 p.m., Jeff McKenna wrote:
     > 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]>
     >> <mailto:[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>
    <https://geographika.net <https://geographika.net>>
     >>     twitter: @geographika
     >

_______________________________________________
MapServer-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapserver-dev

Reply via email to