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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
