<!DOCTYPE html><html><head><title></title><style type="text/css">#fastmail-quoted p.fastmail-quoted-MsoNormal,#fastmail-quoted p.fastmail-quoted-MsoNoSpacing{margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hello again,<br></div><div><br></div><div>After reading through various header files again and the SWIG docs I think I understand better how it fits together. <br></div><div><br></div><div>#ifndef SWIG..#endif guards are added throughout the header file so when it is included via %include "../../mapows.h" only the selected functions are exposed. <br></div><div><br></div><div>I'm not sure if there is a standard way of adding the guards - it seems to be added for individual structs and groups of functions throughout the header file so I tried to fit with this convention - it does make for a large diff though to review. <br></div><div><br></div><div>Now only gmlItemObj is exposed (as an immutable object), and gmlItemListObj (although this will only be available when USE_WMS_SVR and USE_WFS_SVR are defined. <br></div><div><br></div><div>Exposing only the relevant parts of the header file fixes the C# issue. <br></div><div><br></div><div>Seth<br></div><div><br></div><div><br></div><div id="sig62266145"><div class="signature">--<br></div><div class="signature">web:http://geographika.co.uk<br></div><div class="signature">twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Sun, Mar 17, 2019, at 12:48 AM, Seth G wrote:<br></div><blockquote type="cite" id="fastmail-quoted"><div>Hi,<br></div><div><br></div><div>I implemented a simple addition to MapScript to retrieve the gmlItemObj for a layer item (field) and added to the pull request. <br></div><div>This currently works for the Python bindings but is throwing an error for C# I'll look into. <br></div><div><br></div><div>To use gmlItemObj I had to include mapows.h in mapscript.i. When I initially did this there were 28 errors similar to below:<br></div><div><br></div><div>mapscriptPYTHON_wrap.obj : error LNK2019: unresolved external symbol msWMSDispatch referenced in function _wrap_msWMSDispatch<br></div><div><br></div><div>The relevant commit is at: <a href="https://github.com/mapserver/mapserver/pull/5765/commits/0260296eecfb8b9bad979fc20ba5f9034ca37ffb">https://github.com/mapserver/mapserver/pull/5765/commits/0260296eecfb8b9bad979fc20ba5f9034ca37ffb</a> (Ill see what happened to the whitespace in this commit and revert with just the relevant changes). <br></div><div><br></div><div>I simply added the macro MS_DLL_EXPORT to export all these functions and was able to build and test the MapScript bindings. <br></div><div>All the other header files included in SWIG have #ifndef SWIG guards everywhere. Is anyone able to explain to me the purpose of these and provide examples of where these should be added to mapows.h?<br></div><div><br></div><div>Seth<br></div><div><br></div><div id="fastmail-quoted-sig62266145"><div class="fastmail-quoted-signature">--<br></div><div class="fastmail-quoted-signature">web:http://geographika.co.uk<br></div><div class="fastmail-quoted-signature">twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Sat, Mar 16, 2019, at 11:58 AM, Lime, Steve D (MNIT) wrote:<br></div><blockquote id="fastmail-quoted-fastmail-quoted" type="cite"><div>I wish we could make it less GMLish and more generic. For example, it feels odd in MVT code to be relying on what feels like format-specific metadata. The various service specs can use a generic “ows” or service specific metadata namespaces. Could do the same
for output... “out” as the generic namespace with “gml”, “mvt”, “ogr”, “kml” as specific namespaces.<br></div><div><br></div><div>gmlItemObj and gmlItemListObj could also be renamed more generically and the latter could become iteminfo as part of a layer. A cast function for type conversations would also be helpful for more standard use.<br></div><div><br></div><div>Just thinking out loud - I know that’s way more than you want to get into,<br></div><div><br></div><div>—Steve<br></div><div><br></div><div><hr style="display:inline-block;width:98%;"><br></div><div id="fastmail-quoted-fastmail-quoted-divRplyFwdMsg" dir="ltr"><div><span style="font-family:Calibri, sans-serif" class="font"><span style="color:rgb(0, 0, 0)" class="colour"><b>From:</b> mapserver-dev <mapserver-dev-bounces@lists.osgeo.org> on behalf of Seth G <sethg@geographika.co.uk><br> <b>Sent:</b> Friday, March 15, 2019 6:58:41 PM<br> <b>To:</b> mapserver-dev@lists.osgeo.org<br> <b>Subject:</b> Re: [mapserver-dev] Questions on MapServer architecture and attribute conversions</span></span></div><div> <br></div></div><div class="fastmail-quoted-fastmail-quoted-BodyFragment"><span style="font-size:13px" class="size"><span style="font-size:11pt" class="size"><div class="fastmail-quoted-fastmail-quoted-PlainText"><div>Hi Steve, Even,<br></div><div><br></div><div>Thanks for your replies. Thinking back I think I've run into the issue of strings being used for int fields from a database, and CLASS expressions. <br></div><div><br></div><div>I may make an attempt at the following based on both of your comments:<br></div><div><br></div><div>- add gmlItemObj (and also gmlItemListObj) as classes to MapScript<br></div><div>- allow msGMLGetItems to be called on a layerObj to populate this list<br></div><div>- allow this list to be associated/passed to a method on a shapeObj, and use the GML types to set the output attribute types<br></div><div>- if there are no field definitions supplied then attribute names will simply be indexes, and all values strings<br></div><div><br></div><div>Seth<br></div><div>--<br></div><div>web:http://geographika.co.uk<br></div><div>twitter: @geographika<br></div><div><br></div><div>On Thu, Mar 14, 2019, at 10:14 PM, Lime, Steve D (MNIT) wrote:<br></div><div>> Couple of questions here...<br></div><div>> <br></div><div>> On your pull request. I don't think there's a need for a RFC given the <br></div><div>> scope of the change. it's not breaking anything and seems like a nice <br></div><div>> addition - I certainly defer to your expertise as the Python MapScript <br></div><div>> maintainer. I guess it's never a bad idea to alert the -dev list and <br></div><div>> take your email as that notice - so +1 from me.<br></div><div>> <br></div><div>> On your assumptions, both are correct. <br></div><div>> <br></div><div>> On item types, it's funny this hasn't come up more over the years. Type <br></div><div>> conversions seem to happen either for output using the metadata <br></div><div>> referenced or in the expression handling based on context. You're <br></div><div>> correct the that MapScript, most of the time you'd get the column/item <br></div><div>> names from layer but not always since you can work with shapefiles <br></div><div>> directly and independently of a layerObj or mapObj.<br></div><div>> <br></div><div>> Each layer has an attribute has something called iteminfo and it holds <br></div><div>> the index value associated with corresponding value in the items array. <br></div><div>> So you'd look up the item someone wanted for labeling purposes (or <br></div><div>> whatever) and would know what value to grab from a shapes values array. <br></div><div>> Those item index values are stored all over the place (e.g. labelitem <br></div><div>> and labelitemindex). I think with a scheme like Even describes <br></div><div>> items/iteminto could be replaced by one property (items) that would <br></div><div>> equate to an array of field definitions and then specific things like a <br></div><div>> labelitem becomes a struct consisting of a string and a pointer to one <br></div><div>> of the items. For some reason I thought Dan made a run at that at one <br></div><div>> point but I might be mistaken.<br></div><div>> <br></div><div>> -----Original Message-----<br></div><div>> From: mapserver-dev [<a href="mailto:mapserver-dev-bounces@lists.osgeo.org">mailto:mapserver-dev-bounces@lists.osgeo.org</a>] On <br></div><div>> Behalf Of Even Rouault<br></div><div>> Sent: Thursday, March 14, 2019 11:39 AM<br></div><div>> To: mapserver-dev@lists.osgeo.org<br></div><div>> Subject: Re: [mapserver-dev] Questions on MapServer architecture and <br></div><div>> attribute conversions<br></div><div>> <br></div><div>> Seth,<br></div><div>> <br></div><div>> > <br></div><div>> > I've created a pull request to add a __geo_interface__ to the Python<br></div><div>> > MapScript PointObj, LineObj, and ShapeObjs. This allows Python scripts to<br></div><div>> > easily share MapScript objects with other Python geospatial libraries such<br></div><div>> > as Shapely, QGIS, and ArcPy. It also completes a nice cycle as Sean Gillies<br></div><div>> > was a core developer of the MapScript Python bindings and created<br></div><div>> > __geo_interface__. This only affects the Python MapScript bindings - do I<br></div><div>> > need to create a RFC or ask for a vote to merge this for a 7.4 release?<br></div><div>> > <br></div><div>> > I also have a few questions on the internal architecture of MapServer<br></div><div>> > classes. Could other devs confirm (or correct) the following assumptions?<br></div><div>> > <br></div><div>> > - the shapeObj has no link back to a layerObj - they are completely<br></div><div>> > independent with no way to get a reference to a layer from a shape - all<br></div><div>> > shapeObj attribute values are stored internally as strings<br></div><div>> <br></div><div>> Yes that's my understanding too.<br></div><div>> <br></div><div>> > <br></div><div>> > To get attribute names for a shapeObj I had to get retrieve them from the<br></div><div>> > relevant layerObj and store these in a new property on the shapeObj in<br></div><div>> > Python MapScript. I can then output something like the following:<br></div><div>> > <br></div><div>> > "properties": {<br></div><div>> > "guid": "954BADBF-2891-48ED-A132-AED39C60E4C9",<br></div><div>> > "featureid": "203529",<br></div><div>> > "classid": "12"<br></div><div>> > }<br></div><div>> > <br></div><div>> > It would be nice to be able to convert the property values to their relevant<br></div><div>> > types e.g. integers and floats. Looking through the MapServer source they<br></div><div>> > seem to only be converted to types using METADATA blocks and<br></div><div>> > "gml_FIELD_NAME_type" "datatype" and in certain cases e.g. in<br></div><div>> > mapogroutput.c Are these conversions all handled differently for different<br></div><div>> > data inputs? Is there an easy way to reuse these conversions in MapScript?<br></div><div>> <br></div><div>> Yes this lack of proper typing on layer attributes is a bit inconvenient and <br></div><div>> causes lot of adhoc coding in various areas of the code base: ogroutput, OGC <br></div><div>> filtering, WFS, GML output, MVT output, etc.<br></div><div>> The fundamental issue is that layerObj::items is just an array of field names.<br></div><div>> <br></div><div>> For brainstorming... A potential solution could take inspiration from what is <br></div><div>> done in GDAL where:<br></div><div>> OGRLayer (~ equivalent of layerObj) -> contains a OGRFeatureDefn<br></div><div>> OGRFeature (~ equivalent of shapeObj) -> points to a OGRFeatureDefn, and has <br></div><div>> an array of field values<br></div><div>> <br></div><div>> A OGRFeatureDefn contains (among other things) an array of OGRFieldDefn<br></div><div>> A OGRFieldDefn is a set of attribute: field name, field type, etc...<br></div><div>> <br></div><div>> Or if not doing a majorhaul, have indeed a pointer from shapeObj back to <br></div><div>> layerObj (which interesting lifetime consideration, but I'm not sure MapScript <br></div><div>> really shines on maintaining object ownership), and use information returned <br></div><div>> by msGMLGetItems().<br></div><div>> <br></div><div>> <br></div><div>> Even<br></div><div>> <br></div><div>> <br></div><div>> -- <br></div><div>> Spatialys - Geospatial professional services<br></div><div>> <a href="https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com&data=02%7C01%7Csteve.lime%40state.mn.us%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636882911288492978&sdata=gq%2FwxERwIC7hIsUULQuBdz5NuWGPSjEEejynXTrU%2BWc%3D&reserved=0"> https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com&data=02%7C01%7Csteve.lime%40state.mn.us%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636882911288492978&sdata=gq%2FwxERwIC7hIsUULQuBdz5NuWGPSjEEejynXTrU%2BWc%3D&reserved=0</a><br></div><div>> _______________________________________________<br></div><div>> mapserver-dev mailing list<br></div><div>> mapserver-dev@lists.osgeo.org<br></div><div>> <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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636882911288492978&sdata=K6js4DgRQJ4giCNpYqJ3oROAb7HQg3W6xHJaAbXgUxI%3D&reserved=0"> 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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636882911288492978&sdata=K6js4DgRQJ4giCNpYqJ3oROAb7HQg3W6xHJaAbXgUxI%3D&reserved=0</a><br></div><div>> _______________________________________________<br></div><div>> mapserver-dev mailing list<br></div><div>> mapserver-dev@lists.osgeo.org<br></div><div>> <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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C636882911288502991&sdata=48CiR%2B8XMq030GchIzqmpAdse4sgV1b9Fvjk8Jzt%2Fq8%3D&reserved=0"> 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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C636882911288502991&sdata=48CiR%2B8XMq030GchIzqmpAdse4sgV1b9Fvjk8Jzt%2Fq8%3D&reserved=0</a><br></div><div>_______________________________________________<br></div><div>mapserver-dev mailing list<br></div><div>mapserver-dev@lists.osgeo.org<br></div><div><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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C636882911288502991&sdata=48CiR%2B8XMq030GchIzqmpAdse4sgV1b9Fvjk8Jzt%2Fq8%3D&reserved=0">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%7C8af807e4be164b6cb28608d6a9a229ad%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C636882911288502991&sdata=48CiR%2B8XMq030GchIzqmpAdse4sgV1b9Fvjk8Jzt%2Fq8%3D&reserved=0</a><br></div></div></span></span></div></blockquote><div><br></div><div>_______________________________________________<br></div><div>mapserver-dev mailing list<br></div><div>mapserver-dev@lists.osgeo.org<br></div><div>https://lists.osgeo.org/mailman/listinfo/mapserver-dev<br></div></blockquote><div><br></div></body></html>