[mapserver-dev] OPENOPTION (was Re: Dropping support for GDAL < 2 ?)

Lime, Steve D (MNIT) steve.lime at state.mn.us
Fri Aug 23 06:58:47 PDT 2019

Yes, I would leave it to driver owners to capitalize on CONNECTIONOPTIONS (and DATAOPTIONS - good idea!).


From: Even Rouault <even.rouault at spatialys.com>
Sent: Friday, August 23, 2019 8:55 AM
To: Lime, Steve D (MNIT) <steve.lime at state.mn.us>
Cc: mapserver-dev at lists.osgeo.org <mapserver-dev at lists.osgeo.org>
Subject: Re: [mapserver-dev] OPENOPTION (was Re: Dropping support for GDAL < 2 ?)

This message may be from an external email source.
Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.

On vendredi 23 août 2019 13:30:56 CEST Lime, Steve D (MNIT) wrote:
> Would CONNECTIONOPTIONS be more generic? I could see that being useful for
> other drivers where key:value pairs are used as part of the configuration.

Yes, I agree that the mechanism could potentially be used for other connection

For completness, you'd probably also want a DATAOPTIONS to pass options
specific to the DATA keyword. I've always found the syntax for PostGIS data to
be a bit awkward.

So instead of

DATA "the_geom from (select * from polygon3d order by id) as foo using
srid=27700 using unique id"

you could have

DATA "select * from polygon3d order by id"
        "geometry_column"       "the_geom"
        "srid"                                  "27700"
        "unique_column"         "id"

But this is just food for thought, and we probably don't want to break
existing PostGIS DATA syntax.
My scope for now would be just CONNECTIONOPTIONS and implementation for GDAL
and OGR connections.

> For 8.0 a broader conversion of the syntax for layer->processing and
> outputformat->formatoptions could be implemented. For the latter you'd get:
>   NAME "kayml"
>   MIMETYPE "application/vnd.google-earth.kml+xml"
>     "FILE" "myTemplate.kml"
>     "ATTACHMENT" "queryResults.kml"
>   END
> In this case you could ensure backwards compatibility by adding recognizing
> FORMATOPTION as a shortcut.
> Perhaps a new PROCESSINGOPTIONS block should be added and PROCESSING is
> handled as a shortcut for backwards compatability.

Makes sense


Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20190823/bf238a6f/attachment.html>

More information about the mapserver-dev mailing list