[gdal-dev] OGR/SQLite : SELECT GEOMETRY failes on layer copy

[Even Rouault]

Anders,

2 things :
* There was a bug specific to the fact that you copy from a SQL result layer 
(by opposition with a table layer). Fixed by 
http://trac.osgeo.org/gdal/ticket/3617

* You also need to remove the "as G" from your SQL request. Otherwise the 
SQLite driver will not be able to recognize the BLOB column as a geometry one 
(it would write the data, but not add the info in the geometry_column table).

The OGR API can return the geometry column name (if available). The call is 
OGRLayer::GetGeometryColumn()

Best regards,

Even

Le Friday 04 June 2010 10:08:32 Anders Moe, vous avez écrit :
> Hi everyone
>
> I'm using OGR with the SQLite driver, calling
>
> OGR::DataSource::ExecuteSQL ()
>
> By examining the sqlite file I've discovered that the geometry column is
> named , well, GEOMETRY.
>
> So I do something like
>
> SELECT name, GEOMETRY as G from world
>
> which gives me a resulting layer with these two columns. But when copying
> that layer using
>
> OGRDataSource::CopyLayer  ( )
>
> I'm getting
>
> In GetNextRawFeature(): sqlite3_step() : not an error
>
> I guess that the geometry BLOB column is not recognized as geometry during
> the copy, maybe.
>
> So : Does anyone know how to do these kinds of SQL operations that preserve
> the geometry column in a way that can be used in subsequent operations,
> like layer copying ?
>
>  Also, the OGRAPI does not seem to support any notion of geometry column
> name. Anyone know a way around this ?
>
>
> Cheers,
> Anders