[mapserver-users] Issue with run-time substitution?

[Steve Lime]

It's probably a wash. The filer is integrated into the data statement anyway, I'd go with DATA just because it's easier to see what's going on. Steve

Sent from my iPad

On Aug 30, 2011, at 1:09 PM, pcreso at pcreso.com wrote:

> One question...
> 
> From a performance perspective, I would have thought that having the fliter
> FILTER  (stype='B' and uc='%vucv%')
> 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.
> 
> Is there any advantage in using FILTER instead of an SQL WHERE clause for this?
> 
> Brent Wood
> 
> --- On Tue, 8/30/11, Julien Cigar <jcigar at ulb.ac.be> wrote:
> 
> From: Julien Cigar <jcigar at ulb.ac.be>
> Subject: Re: [mapserver-users] Issue with run-time substitution?
> To: mapserver-users at lists.osgeo.org
> Date: Tuesday, August 30, 2011, 11:49 PM
> 
> On 08/30/2011 13:43, Stephen Davies wrote:
> > I am running mapserver 6.0.1 with map files migrated from 5.6.3.
> >
> > One of my map files has stopped working properly and I suspect that it may be a
> > bug in the 6.0.1 run-time substitution code.
> >
> > The relevant map file layer sections look like this:
> >
> >     LAYER
> >        CONNECTIONTYPE postgis
> >        NAME "battery"
> >        DATA "geom from wmd  using unique id using SRID=4283"
> >        CONNECTION "user=scldad dbname=benparts"
> >        STATUS ON
> >        TYPE POINT
> >        VALIDATION
> >          vucv '[0-9]*_[0-9]*'
> >        END
> >        FILTER  (stype='B' and uc='%vucv%')
> >        PROJECTION
> >          "init=epsg:4283"
> >        END
> >        MAXSCALE 5000000
> >        LABELITEM "label"
> >        CLASSITEM "state"
> >        CLASS
> >          EXPRESSION "G"
> >          STYLE
> >            COLOR        0 255 0
> >            SYMBOL 'dot'
> >            SIZE 7
> >            OFFSET 17 0
> >          END
> >          LABEL
> >            POSITION CR
> >            TYPE TRUETYPE
> >            FONT arial
> >            SIZE 8
> >            COLOR 0 255 0
> >            OFFSET 20 0
> >            FORCE TRUE
> >            STYLE
> >                  GEOMTRANSFORM 'labelpoly'
> >                  COLOR   255 255 255
> >            END
> >          END
> >        END
> > .
> > .
> > END
> >
> > There are twelve layers with essentially the same definition apart from the
> > STYPE values.
> >
> > The invoking URL has&vucv=137_11 but the postgresql log reveals that no
> > substitution has occurred. The final pgsql command still has '%vucv%'.
> >
> > I suspect that having more than one FILTER with the same substitution breaks
> > things as all other substitutions work fine.
> >
> > (I also tried putting the substitution in the DATA entry but with no better
> > result.)
> 
> You should use a METADATA section, something like:
> 
> METADATA
>    "vucv_validation_pattern" '[0-9]*_[0-9]*'
> END
> 
> instead of VALIDATION
> 
> >
> > Cheers,
> > Stephen
> >
> 
> 
> -- 
> No trees were killed in the creation of this message.
> However, many electrons were terribly inconvenienced.
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20110831/7cc4942c/attachment.html