Multiple rows in subquery

Question

I am trying to create a context of exclusion zone in my layer.

I am trying the following Map File/SQL combo

DATA "geom FROM public.data"
FILTER "layer = %layer_id% AND ST_CONTAINS(ALL(SELECT the_geom FROM public.exclusion_zone WHERE layer = %layer_id%), geom) != true"

Obviously this breaks when there are more then 1 exclusion zone, so how do I do this?

I've tried storedProc's already only to be told MapServer can't find it's SRID as it doesn't appear in the geometry table

The error I am receiving is thus

Query error. Error (ERROR: more than one row returned by a subquery used as an expression ) executing query

Answer 1

Try this:

DATA "geom FROM public.data"
FILTER "
    layer = %layer_id% and
    not exists
    (
        SELECT *
        FROM public.exclusion_zone
        WHERE layer = %layer_id% and ST_CONTAINS(the_geom, geom)
    )

Answer 2

This looks more like a MapServer related question than a PostgreSQL/PostGIS one.
What version of MapServer are you using?

It's prefereable to avoid the FILTER parameter and use a subquery to retrieve your data from postgis explicitly providing the SRID and unique id field: you get better performance, more control, less headaches caused by MapServer and PostgreSQL query optimizer "missunderstandings".

I have no idea about your actual data, but pasting your lines togheter and assuming there is a gid field in the public.data table, you should get something like that:

DATA "geom from (
        SELECT gid, geom 
            FROM public.data 
            WHERE layer = %layer_id% AND ST_CONTAINS(ALL(SELECT the_geom FROM public.exclusion_zone WHERE layer = %layer_id%), geom) != true 
    ) as layer using unique gid using srid = %layer_id%"

Of course change the %srid% according to your data, or use -1. Depending on your PostGIS and MapServer version you could even avoid it (ok, it depends strictly on your data and query too), letting MapServer to get it for you, but it's an useless overhead.

About your query, it gives me the feeling something could be optimized in there, but I guess this is just a test query to be replaced with the final one.