<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
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>
<br>
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>
<br>
Just thinking out loud - I know that’s way more than you want to get into,<br>
<br>
—Steve<br>
<br>
<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 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</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi Steve, Even,<br>
<br>
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>
<br>
I may make an attempt at the following based on both of your comments:<br>
<br>
- add gmlItemObj (and also gmlItemListObj) as classes to MapScript<br>
- allow msGMLGetItems to be called on a layerObj to populate this list<br>
- 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>
- if there are no field definitions supplied then attribute names will simply be indexes, and all values strings<br>
<br>
Seth<br>
--<br>
web:http://geographika.co.uk<br>
twitter: @geographika<br>
<br>
On Thu, Mar 14, 2019, at 10:14 PM, Lime, Steve D (MNIT) wrote:<br>
> Couple of questions here...<br>
> <br>
> On your pull request. I don't think there's a need for a RFC given the <br>
> scope of the change. it's not breaking anything and seems like a nice <br>
> addition - I certainly defer to your expertise as the Python MapScript <br>
> maintainer. I guess it's never a bad idea to alert the -dev list and <br>
> take your email as that notice - so +1 from me.<br>
> <br>
> On your assumptions, both are correct. <br>
> <br>
> On item types, it's funny this hasn't come up more over the years. Type <br>
> conversions seem to happen either for output using the metadata <br>
> referenced or in the expression handling based on context. You're <br>
> correct the that MapScript, most of the time you'd get the column/item <br>
> names from layer but not always since you can work with shapefiles <br>
> directly and independently of a layerObj or mapObj.<br>
> <br>
> Each layer has an attribute has something called iteminfo and it holds <br>
> the index value associated with corresponding value in the items array. <br>
> So you'd look up the item someone wanted for labeling purposes (or <br>
> whatever) and would know what value to grab from a shapes values array. <br>
> Those item index values are stored all over the place (e.g. labelitem <br>
> and labelitemindex). I think with a scheme like Even describes <br>
> items/iteminto could be replaced by one property (items) that would <br>
> equate to an array of field definitions and then specific things like a <br>
> labelitem becomes a struct consisting of a string and a pointer to one <br>
> of the items. For some reason I thought Dan made a run at that at one <br>
> point but I might be mistaken.<br>
> <br>
> -----Original Message-----<br>
> From: mapserver-dev [<a href="mailto:mapserver-dev-bounces@lists.osgeo.org">mailto:mapserver-dev-bounces@lists.osgeo.org</a>] On
<br>
> Behalf Of Even Rouault<br>
> Sent: Thursday, March 14, 2019 11:39 AM<br>
> To: mapserver-dev@lists.osgeo.org<br>
> Subject: Re: [mapserver-dev] Questions on MapServer architecture and <br>
> attribute conversions<br>
> <br>
> Seth,<br>
> <br>
> > <br>
> > I've created a pull request to add a __geo_interface__ to the Python<br>
> > MapScript PointObj, LineObj, and ShapeObjs. This allows Python scripts to<br>
> > easily share MapScript objects with other Python geospatial libraries such<br>
> > as Shapely, QGIS, and ArcPy. It also completes a nice cycle as Sean Gillies<br>
> > was a core developer of the MapScript Python bindings and created<br>
> > __geo_interface__. This only affects the Python MapScript bindings - do I<br>
> > need to create a RFC or ask for a vote to merge this for a 7.4 release?<br>
> > <br>
> > I also have a few questions on the internal architecture of MapServer<br>
> > classes. Could other devs confirm (or correct) the following assumptions?<br>
> > <br>
> > - the shapeObj has no link back to a layerObj - they are completely<br>
> > independent with no way to get a reference to a layer from a shape - all<br>
> > shapeObj attribute values are stored internally as strings<br>
> <br>
> Yes that's my understanding too.<br>
> <br>
> > <br>
> > To get attribute names for a shapeObj I had to get retrieve them from the<br>
> > relevant layerObj and store these in a new property on the shapeObj in<br>
> > Python MapScript. I can then output something like the following:<br>
> > <br>
> > "properties": {<br>
> > "guid": "954BADBF-2891-48ED-A132-AED39C60E4C9",<br>
> > "featureid": "203529",<br>
> > "classid": "12"<br>
> > }<br>
> > <br>
> > It would be nice to be able to convert the property values to their relevant<br>
> > types e.g. integers and floats. Looking through the MapServer source they<br>
> > seem to only be converted to types using METADATA blocks and<br>
> > "gml_FIELD_NAME_type" "datatype" and in certain cases e.g. in<br>
> > mapogroutput.c Are these conversions all handled differently for different<br>
> > data inputs? Is there an easy way to reuse these conversions in MapScript?<br>
> <br>
> Yes this lack of proper typing on layer attributes is a bit inconvenient and <br>
> causes lot of adhoc coding in various areas of the code base: ogroutput, OGC <br>
> filtering, WFS, GML output, MVT output, etc.<br>
> The fundamental issue is that layerObj::items is just an array of field names.<br>
> <br>
> For brainstorming... A potential solution could take inspiration from what is <br>
> done in GDAL where:<br>
> OGRLayer (~ equivalent of layerObj) -> contains a OGRFeatureDefn<br>
> OGRFeature (~ equivalent of shapeObj) -> points to a OGRFeatureDefn, and has <br>
> an array of field values<br>
> <br>
> A OGRFeatureDefn contains (among other things) an array of OGRFieldDefn<br>
> A OGRFieldDefn is a set of attribute: field name, field type, etc...<br>
> <br>
> Or if not doing a majorhaul, have indeed a pointer from shapeObj back to <br>
> layerObj (which interesting lifetime consideration, but I'm not sure MapScript <br>
> really shines on maintaining object ownership), and use information returned <br>
> by msGMLGetItems().<br>
> <br>
> <br>
> Even<br>
> <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%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>
> _______________________________________________<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%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>
> _______________________________________________<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%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>
_______________________________________________<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%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></div>
</span></font></div>
</body>
</html>