aleda_freeman ha scritto:
MassGIS would also love an IN ability.. TOWN_ID IN (3,6,39) .. because we
have 351 towns in Massachusetts and while we just got a long WMS Get URL to
squeak past our tomcat and squid, it only works in Firefox. IE has a
smaller URL limit of 2,083 bytes. See long example at bottom:
http://lyceum.massgis.state.ma.us/wiki/doku.php?id=cql
As a workaround for this specific case, since most of the towns are matched by that filter, why don't you reverse it, and ask the town not to be among the ones that do not have reports about the American Robin? The filter would be quite a bit smaller.
As for a real fix, hmmm... CQL has been implemented as the standard
asks for, with no extensions, but there was a proposal underway
to make an extension of it, labelled TXT, that would have some extras:
http://docs.codehaus.org/display/GEOTOOLS/TXT+Language+Analysis
"property in (list)" is not among them unfortunately. Mauricio,
you have been following that proposal, what is its state?
What about adding this extra extension to it? It would have to
parse into a list of or-ed PropertyIsEqualsTo, since the OGC filter
standard does not have a "PropertyInList" element, but at
least it would make for a more compact, easier to read filter
expression.
Another approach to solve this issue could be to split the request
into two, first a POST request to store the filter on the server side,
getting back a filter identifier, and then use the filter identifier
in the wms requests. This is a bit far fetched, but it may also be
one solution to support WFS 1.2 feature paging, since the spec says the returned page should point to the next page (so, a GET request),
meaning we'll need ways to store big WFS requests on the server side anyways (having a way to store the filter and refer back to it using an identifier in a GET would be one solution to that problem).
Anyways, this is just me thinking aloud, we have bigger fishes to
fry for the next few months.
Cheers
Andrea