[mapserver-dev] RFC 125: Support for CONNECTIONOPTIONS in mapfiles

Even Rouault even.rouault at spatialys.com
Mon Sep 30 16:10:25 PDT 2019

On lundi 30 septembre 2019 22:51:43 CEST Lime, Steve D (MNIT) wrote:
> Hi Even (and all): I think the RFC looks solid. In terms of implementation I
> was wondering if we might consider a single OPTIONS block so that the
> concept (and keyword) might build some commonality across objects (for
> example, OUTPUTFORMAT could use this). I'd leave METADATA and VALIDATION
> blocks alone. So one could write:
>   # data options
>   "key" "value"
>   # connection options
>   # processing options
>   "NATIVE_FILTER" "d=234"
> END 
> as opposed to creating a DATAOPTIONS, CONNECTIONOPTIONS and
> PROCESSINGOPTIONS... That would make the mapfile syntax cleaner and keep
> MapScript simpler.

Hum, but how would the code know which of those are for DATA, CONNECTION, 
For example, GDAL drivers will warn if they are passed an open option they 
don't handle.
With different blocks, we (or any upper-level layer generating mapfile) might 
be able to add more easily validation at a later point rather than if we mix 
(It's rather unlikely but there's also the risk where a proccessing option 
might have the same name as a driver open option...)

Spatialys - Geospatial professional services

More information about the mapserver-dev mailing list