<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">One question...<br><br>From a performance perspective, I would have thought that having the fliter<br> FILTER (stype='B' and uc='%vucv%')<br>inside the DATA statement SQL would be faster, as only the relevant records would be returned to mapserver, & Postgres would be more efficient at doing this.<br><br>Is there any advantage in using FILTER instead of an SQL WHERE clause for this?<br><br>Brent Wood<br><br>--- On <b>Tue, 8/30/11, Julien Cigar <i><jcigar@ulb.ac.be></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Julien Cigar <jcigar@ulb.ac.be><br>Subject: Re: [mapserver-users] Issue with run-time substitution?<br>To: mapserver-users@lists.osgeo.org<br>Date: Tuesday, August 30, 2011, 11:49 PM<br><br><div class="plainMail">On 08/30/2011 13:43, Stephen Davies
wrote:<br>> I am running mapserver 6.0.1 with map files migrated from 5.6.3.<br>><br>> One of my map files has stopped working properly and I suspect that it may be a<br>> bug in the 6.0.1 run-time substitution code.<br>><br>> The relevant map file layer sections look like this:<br>><br>> LAYER<br>> CONNECTIONTYPE postgis<br>> NAME "battery"<br>> DATA "geom from wmd using unique id using SRID=4283"<br>> CONNECTION "user=scldad dbname=benparts"<br>> STATUS ON<br>> TYPE POINT<br>> VALIDATION<br>> vucv '[0-9]*_[0-9]*'<br>> END<br>> FILTER (stype='B' and uc='%vucv%')<br>>
PROJECTION<br>> "init=epsg:4283"<br>> END<br>> MAXSCALE 5000000<br>> LABELITEM "label"<br>> CLASSITEM "state"<br>> CLASS<br>> EXPRESSION "G"<br>> STYLE<br>> COLOR 0 255 0<br>> SYMBOL 'dot'<br>> SIZE 7<br>> OFFSET 17 0<br>> END<br>> LABEL<br>> POSITION CR<br>> TYPE TRUETYPE<br>> FONT
arial<br>> SIZE 8<br>> COLOR 0 255 0<br>> OFFSET 20 0<br>> FORCE TRUE<br>> STYLE<br>> GEOMTRANSFORM 'labelpoly'<br>> COLOR 255 255 255<br>> END<br>> END<br>> END<br>> .<br>> .<br>> END<br>><br>> There are twelve layers with essentially the same definition apart from the<br>> STYPE values.<br>><br>> The invoking URL has&vucv=137_11 but the postgresql log reveals that no<br>> substitution has occurred. The final pgsql command still has
'%vucv%'.<br>><br>> I suspect that having more than one FILTER with the same substitution breaks<br>> things as all other substitutions work fine.<br>><br>> (I also tried putting the substitution in the DATA entry but with no better<br>> result.)<br><br>You should use a METADATA section, something like:<br><br>METADATA<br> "vucv_validation_pattern" '[0-9]*_[0-9]*'<br>END<br><br>instead of VALIDATION<br><br>><br>> Cheers,<br>> Stephen<br>><br><br><br>-- <br>No trees were killed in the creation of this message.<br>However, many electrons were terribly inconvenienced.<br></div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>mapserver-users mailing list<br><a ymailto="mailto:mapserver-users@lists.osgeo.org" href="/mc/compose?to=mapserver-users@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br><a
href="http://lists.osgeo.org/mailman/listinfo/mapserver-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br></div></blockquote></td></tr></table>