<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">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.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">For 8.0 a broader conversion of the syntax for layer->processing and outputformat->formatoptions could be implemented. For the latter you'd get:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"></p>
<div>OUTPUTFORMAT</div>
<div> NAME "kayml"</div>
<div> DRIVER "TEMPLATE"</div>
<div> MIMETYPE "application/vnd.google-earth.kml+xml"</div>
<div> OPTIONS </div>
<div> "FILE" "myTemplate.kml"</div>
<div> "ATTACHMENT" "queryResults.kml"</div>
<div> END</div>
<div>END</div>
<div><br>
</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
In this case you could ensure backwards compatibility by adding recognizing FORMATOPTION as a shortcut.</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
Perhaps a new PROCESSINGOPTIONS block should be added and PROCESSING is handled as a shortcut for backwards compatability.</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
--Steve</div>
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, Helvetica, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<br>
</div>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> mapserver-dev <mapserver-dev-bounces@lists.osgeo.org> on behalf of Even Rouault <even.rouault@spatialys.com><br>
<b>Sent:</b> Friday, August 23, 2019 7:01 AM<br>
<b>To:</b> mapserver-dev@lists.osgeo.org <mapserver-dev@lists.osgeo.org><br>
<b>Subject:</b> [mapserver-dev] OPENOPTION (was Re: Dropping support for GDAL < 2 ?)</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
> A new Mapfile keyword will require changes for SWIG support I believe?<br>
<br>
In my initial implementation, this adds a new member (a hashTableObj) in the<br>
struct layerObj. I don't think this would require specific SWIG changes.<br>
<br>
><br>
> My preference from a syntax point of view (although blissfully unaware of<br>
> the implementation issues it will raise!) would be to turn PROCESSING into<br>
> a block with the same syntax as METADATA e.g.<br>
><br>
> PROCESSING<br>
> "CONTOUR_INTERVAL" "5"<br>
> "CLUSTER_GET_ALL_SHAPES" ON"<br>
> "OPENOPTION_KEY1" "VALUE1"<br>
> "OPENOPTION_KEY2" "VALUE2"<br>
> END<br>
<br>
On the parser side there would be some complication to distinguish the old<br>
PROCESSING "key=value" syntax with the new block approach. I'm not sure we<br>
have a precedent of that.<br>
<br>
And the processing member of layerObj is not exposed to SWIG currently. It<br>
uses a char** processing + int numprocessing that are inconvenient to bind to<br>
SWIG. They should likely be converted to a hashTableObj to be exposed to SWIG.<br>
<br>
><br>
> SWIG could then use a dict type approach in the same way as METADATA to<br>
> update and add, modify keys and values in the PROCESSING block.<br>
<br>
If OPENOPTION uses a hashTableObj as METADATA does, then this would be similar<br>
to interacting with metadata.<br>
<br>
I'm also open to a block based approach for OPENOPTION if that seems better<br>
OPENOPTION<br>
"key1" "value1"<br>
"key2" "value2<br>
END<br>
<br>
<br>
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="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" id="LPlnk327146" class="OWAAutoLink" previewremoved="true">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</a><br>
_______________________________________________<br>
mapserver-dev mailing list<br>
mapserver-dev@lists.osgeo.org<br>
<a href="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" id="LPlnk33799" class="OWAAutoLink" previewremoved="true">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</a><br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>