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

[pcreso at pcreso.com]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20110830/3536e6c5/attachment.htm>