[Geoserver-users] case-insensitive search

Hi Andrea,

I already mentioned the missing matchCase for PropertyIsLike to OGC back in
the 2005/2006 days :frowning:

See also:

http://feature.opengeospatial.org/forumbb/viewtopic.php?p=978&sid=60ae94c241b32db8ed06a77df6f38a10

and:

http://mail.opengeospatial.org/pipermail/wfs-dev/2005-July/000239.html

OGC by default means case-sensitive, you're right about that.

A datastore options does sound like a good option to me, maybe we a default
value that makes it OGC compliant at least.

Best regards,
Bart

--
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl

--------- Oorspronkelijk bericht --------
Van: Andrea Aime <aaime@anonymised.com>
Naar: Bart van den Eijnden OSGIS <bartvde@anonymised.com>
Cc: geoserver-users@lists.sourceforge.net, Gabriel Roldá n
<groldan@anonymised.com>
Onderwerp: Re: [Geoserver-users] case-insensitive search
Datum: 18/03/08 11:35

Bart van den Eijnden (OSGIS) ha scritto:
&gt; Hi list,
&gt;
&gt; using OCI featureTypes Geoserver/Geotools always adds an UPPER

function to

&gt; the SQL clause, which results in a case-insensitive search by

default.

Hum, this has been an implementation detail for the Oracle data store,
but I'm not sure it's OGC filter compliant. It should probably be turned
into a datastore hint.

&gt; But when using ArcSDE featureTypes, the search is case-sensitive ...
&gt;
&gt; Is case-insensitive search implemented for ArcSDE?
&gt;
&gt; If so, do we need to use the matchCase attribute from Filter 1.1?

Theoretically yes, but a quick investigation in the source code
seems to suggest none of the jdbc based datastores is respecting
the matchCase... ah, but wait, I looked into the oracle data store
and the only UPPERCASE I see is for like comparisons...

The Filter 1.1 spec states:
&quot;The Common Catalog Query Language [4] defines a standard set of
comparison operators (=,&lt;,&gt;,&gt;=,&lt;=,&lt;&gt;). These comparison

operators are

encoded using the complex type BinaryComparisonOpType. This type
definition includes the matchCase attribute which is of type Boolean and
controls whether string comparisons are caseless or not. A value of true
means that string comparisons also match case. This is the default
value. A value of false means that string comparisons are performed
caselessly.&quot;

As you can see, Like is not among the lot, and in fact there is no
isMatchCase attribute for that element.

Yet, the PropertyIsLike definition is simply:
&quot;The &lt;PropertyIsLike&gt; element is intended to encode a character

string

comparison operator with pattern matching. The pattern is defined by a
combination of regular characters, the wildCard character, the
singleChar character, and the escapeChar character. The wildCard
character matches zero or more characters. The singleChar character
matches exactly one character. The escapeChar character is used to
escape the meaning of the wildCard, singleChar and escapeChar

itself.&quot;

Nothing about case sensitiveness. I believe the spec is oriented
towards case sensitive comparisons, but it does not really state
anything about that. Gonna ask on wfs-dev OGC mailing list.

Given that the spec left a hole, and that there is no way to ask
either way within the request, I'd say we could allow admin
to control this behaviour at the datastore level, with the risk
of not being WFS compliant anymore (rationale, the postgis datastore we
use for cite compliancy performs a case sensitive like comparison, and
we're the reference implementation).

Gabriel, what do you think?
Cheers
Andrea

Bart van den Eijnden (OSGIS) ha scritto:

Hi Andrea,

I already mentioned the missing matchCase for PropertyIsLike to OGC back in
the 2005/2006 days :frowning:

See also:

http://feature.opengeospatial.org/forumbb/viewtopic.php?p=978&sid=60ae94c241b32db8ed06a77df6f38a10

and:

http://mail.opengeospatial.org/pipermail/wfs-dev/2005-July/000239.html

OGC by default means case-sensitive, you're right about that.

Well, see the response to my inquiry on wfs-dev:
http://mail.opengeospatial.org/pipermail/wfs-dev/2008-March/000488.html

Which kind of make me feel sick, since a modification in GeoApi would be required to support that, ugh...

Cheers
Andrea