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

[Even Rouault]

> 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
http://www.spatialys.com