[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:
> OPTIONS
> # data options
> "key" "value"
>
> # connection options
> "FLATTEN_NESTED_ATTRIBUTES" "YES"
>
> # 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,
PROCESSING... ?
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
everything.
(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
http://www.spatialys.com
More information about the mapserver-dev
mailing list