Bug#842122: /usr/bin/ogr2ogr: "dialect SQLITE" isn't working as expected

[Nelson A. de Oliveira]

Package: gdal-bin
Version: 2.1.1+dfsg-5
Severity: normal
File: /usr/bin/ogr2ogr

Hi!

With the attached example I can't get a proper output when using
"-dialect SQLITE"

For example, this properly works:

=====
ogr2ogr -update -append -f "ESRI Shapefile" -sql "SELECT NM_TIPO_LO,
NM_TITULO_, NM_NOME_LO FROM \"35032080500_face\"" -t_srs EPSG:4326
merged.shp 35032080500_face.shp
=====

I can see 4 files, as expected: merged.dbf, merged.prj, merged.shp,
merged.shx


Adding "-dialect SQLITE" (remove the merged* files before running):

=====
ogr2ogr -update -append -f "ESRI Shapefile" -dialect SQLITE -sql "SELECT
NM_TIPO_LO, NM_TITULO_, NM_NOME_LO FROM \"35032080500_face\"" -t_srs
EPSG:4326 merged.shp 35032080500_face.shp
=====

ogr2ogr doesn't give any warning or error message, but I can see only
two files being created: merged.dbf and merged.prj
There isn't any shapefile there.

ogr2ogr's manpage says:
=====
       -dialect dialect:
           SQL dialect. In some cases can be used to use (unoptimized) OGR SQL
           instead of the native SQL of an RDBMS by passing OGRSQL. Starting
           with GDAL 1.10, the 'SQLITE' dialect can also be used with any
           datasource.
=====

http://www.gdal.org/ogr_sql_sqlite.html also says:
=====
Since GDAL/OGR 1.10, the SQLite "dialect" can be used as an alternate
SQL dialect to the OGR SQL dialect. This assumes that GDAL/OGR is built
with support for SQLite (>= 3.6), and preferably with Spatialite support
too to benefit from spatial functions.

The SQLite dialect may be used with any OGR datasource, like the OGR SQL
dialect. It is available through the GDALDataset::ExecuteSQL() method by
specifying the pszDialect to "SQLITE". For the ogrinfo or ogr2ogr
utility, you must specify the "-dialect SQLITE" option.

This is mainly aimed to execute SELECT statements (…)
=====

>From what I understand, I can use "-dialect SQLITE" with any datasource
(including shapefiles, I expect)

Is ogr2ogr somehow not doing what it should do, is the documentation
incomplete (ie, we can use the dialect only with some specific cases) or
do I need some coffee, please?

Thank you!

Best regards,
Nelson

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdal-bin depends on:
ii  libc6                       2.24-5
ii  libgcc1                     1:6.2.0-9
ii  libgdal20 [gdal-abi-2-1-1]  2.1.1+dfsg-5
ii  libstdc++6                  6.2.0-9

gdal-bin recommends no packages.

Versions of packages gdal-bin suggests:
pn  libgdal-grass  <none>
ii  python-gdal    2.1.1+dfsg-5

-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.tar.bz2
Type: application/x-bzip2
Size: 635064 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grass-devel/attachments/20161026/29f2028c/attachment-0001.bin>