<div dir="ltr">Hi Even, all,<div>Thanks for the fast and helpful response!</div><div>So, if I need this shortly, I should compile a slightly modified version?</div><div>I can't see myself giving a true solution to the backward compatibility issue ;)</div><div>My problem here is not large.</div><div>The main advantage of caseinsensitive is a compact and accurate query, I was used to seeing if I could just omit the first (capital or not) character.</div><div>But I ran into a case where this produced unwanted results and cmdline gave ERROR 1: Destination buffer too small.</div><div>So I'll put the less compact SQL in a file and use -sql @file.sql for now.</div><div>Thanks,</div><div>Jan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 28, 2019 at 4:25 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On jeudi 28 novembre 2019 16:09:28 CET Jan Heckman wrote:<br>
> Hi everybody,<br>
> According to docs <<a href="https://gdal.org/user/ogr_sql_dialect.html" rel="noreferrer" target="_blank">https://gdal.org/user/ogr_sql_dialect.html</a>>, LIKE and<br>
> ILIKE should be caseinsensitive.<br>
> However, they are not.<br>
> ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 140000<br>
> 485000 WFS:"<a href="http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services" rel="noreferrer" target="_blank">http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services</a>"<br>
> Bestemmingsplangebied -lco ENCODING=UTF-8 -where<br>
> "BeleidsmatigVerantwoordelijkeOverheid LIKE 'Geme%'" produces empty output.<br>
> The clue is that LIKE 'geme%'  (as in the DB 'gemeente'). does produce<br>
> output.<br>
> Replacing LIKE with ILIKE makes no difference.<br>
<br>
Jan,<br>
<br>
That's an interesting case.<br>
<br>
OGR SQL indeeds consider LIKE and ILIKE are identical and case insensitive.<br>
<br>
But... when issuing a -where to a WFS source, OGR turns the SQL into OGC <br>
Filter Encoding so that the filter is evaluated by the server for performance <br>
reasons. When doing so it uses the PropertyIsLike predicate, which is case <br>
sensitive by default. There's a matchCase attribute that could be set to <br>
false.<br>
<br>
So I can see 2 options:<br>
<br>
1) change the WFS translation code to set matchCase=false. Quite easy to <br>
implement. Some backward compatibility consequence for users of WFS sources <br>
that would have dependended on the current behaviour (case sensitivity)<br>
<br>
2) more work. for WFS, have LIKE and ILIKE having two different translations. <br>
But if we do so, as we would need to add a new SWQ_ILIKE operator, and we <br>
should also probably make LIKE and ILIKE be distinct operations on a pure OGR <br>
SQL evaluation (client side). Which has some backward compatibility <br>
implication.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div>