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

[Lime, Steve D (MNIT)]

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.


For 8.0 a broader conversion of the syntax for layer->processing and outputformat->formatoptions could be implemented. For the latter you'd get:


OUTPUTFORMAT
  NAME "kayml"
  DRIVER "TEMPLATE"
  MIMETYPE "application/vnd.google-earth.kml+xml"
  OPTIONS
    "FILE" "myTemplate.kml"
    "ATTACHMENT" "queryResults.kml"
  END
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.

--Steve


________________________________
From: mapserver-dev <mapserver-dev-bounces at lists.osgeo.org> on behalf of Even Rouault <even.rouault at spatialys.com>
Sent: Friday, August 23, 2019 7:01 AM
To: mapserver-dev at lists.osgeo.org <mapserver-dev at lists.osgeo.org>
Subject: [mapserver-dev] OPENOPTION (was Re: Dropping support for GDAL < 2 ?)


> A new Mapfile keyword will require changes for SWIG support I believe?

In my initial implementation, this adds a new member (a hashTableObj) in the
struct layerObj. I don't think this would require specific SWIG changes.

>
> My preference from a syntax point of view (although blissfully unaware of
> the implementation issues it will raise!) would be to turn PROCESSING into
> a block with the same syntax as METADATA e.g.
>
> PROCESSING
>    "CONTOUR_INTERVAL" "5"
>    "CLUSTER_GET_ALL_SHAPES" ON"
>    "OPENOPTION_KEY1" "VALUE1"
>    "OPENOPTION_KEY2" "VALUE2"
> END

On the parser side there would be some complication to distinguish the old
PROCESSING "key=value" syntax with the new block approach. I'm not sure we
have a precedent of that.

And the processing member of layerObj is not exposed to SWIG currently. It
uses a char** processing + int numprocessing that are inconvenient to bind to
SWIG. They should likely be converted to a hashTableObj to be exposed to SWIG.

>
> SWIG could then use a dict type approach in the same way as METADATA to
> update and add, modify keys and values in the PROCESSING block.

If OPENOPTION uses a hashTableObj as METADATA does, then this would be similar
to interacting with metadata.

I'm also open to a block based approach for OPENOPTION if that seems better
OPENOPTION
        "key1" "value1"
        "key2" "value2
END


Even

--
Spatialys - Geospatial professional services
https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com&data=02%7C01%7Csteve.lime%40state.mn.us%7C2d231ecf76024bb5306308d727c1956c%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C637021584697677675&sdata=1M4fgEWOxeT91edSqgLw1%2B%2FeilqNaurlBqU0MxnEEPk%3D&reserved=0
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fmapserver-dev&data=02%7C01%7Csteve.lime%40state.mn.us%7C2d231ecf76024bb5306308d727c1956c%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C637021584697677675&sdata=w4nqoDyBBfy2WvF8l0aFfeX95AfMeagf7JdnR8SCMPQ%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20190823/a7a48bd6/attachment-0001.html>