[gdal-dev] OGR SQL: Excecuting select where column name contains "."

[Even Rouault]

> I can confirm that it is not illegal per se because the following works. I
> hope that the backslashes and everything go through properly.
> 
> ogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows
>  -sql "select \"nom.dept\" from \"tows:dot.test\""
> 
> It is an open WFS server and you can test it with ogrinfo and from your
> code too. However, I will remove the dot.test feature type sooner or
> later. Verify and make your code to work in a similar way than ogrinfo.

Jukka,

I didn't do any test up to now, but now that I've tested with your above 
server, here are my findings and conclusions.

To start, I'm wondering to which extent did you check the result of the above 
ogrinfo command. It "works" for me on GDAL 1.9.2 and GDAL trunk on Linux and 
Windows, but the output is  what Odd-Ragna actually observes, something like :

FIELD_1: String (0.0)
OGRFeature(tows:dot.test):0
  FIELD_1 (String) = nom.dept
  MULTIPOLYGON ((([......])

By studying the code, I have come to the conclusion that whatever the way you 
use to quote or not quote the field name, the presence of a dot in a field name, 
let's say nom.dept, is interpreted by OGR as the dept field of layer nom. As 
layer nom doesn't exist, OGR then interprets it as a string literal, hence the 
observed result. 

In fact, there's a subtle difference : 
- if you don't quote nom.dept, then OGR will know that it is supposed to be a 
field. Then as it doesn't find it, it will report an error : "Unrecognised field 
name nom.dept"
- if you quote it, as there's an ambiguity, it will first try to identify it as 
a field, and as this fails, it fallbacks to interpret is as as string litteral.

There's however a way to workaround this.

You can use :

ogrinfo WFS:http://188.64.1.61/cgi-bin/tinyows
 -sql "select \"foo.nom.dept\" from \"tows:dot.test\" foo"

The layer name tows:dot.test will get an alias foo, and when OGR interprets 
foo.nom.dept is will interpret it as the nom.dept field of layer foo, which 
works now since foo is indeed a valid alias for tows:dot.test !

The bad news is that, at least for the TinyOWS server, it doesn't like the 
request that is sent :

http://188.64.1.61/cgi-
bin/tinyows?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=tows:dot.test&PROPERTYNAME=%28nom.dept,the_geom%29

This generates :

ERROR 1: Error: cannot parse <?xml version='1.0' encoding='UTF-8'?>
<ExceptionReport
 xmlns='http://www.opengis.net/ows'
 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
 xsi:schemaLocation='http://www.opengis.net/ows 
http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd'
 version='1.0.0' language='en'>
 <Exception exceptionCode='NoMatching' locator='GetFeature'>
  <ExceptionText>propertyname values and typename values don't 
match</ExceptionText>
 </Exception>
</ExceptionReport>

TinyOWS doesn't like the nom.dept field. It propably forwards it directly as a 
SQL request to PostgreSQL, which also interprets nom.dept as the dept field of 
table nom. So you're still stuck at the end of the day. Not sure how other WFS 
servers would react and if it is supposed to work.

Conclusion: don't use dot character in field names !

> 
> -Jukka-
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev