Martin, This error is emitted by spatialite.
See https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Shadowed+ROWID+issues Did you check that the FID column name of your input table wasn't rowid ? I could reproduce by forging first such a DB $ ogrinfo test.db -al -so INFO: Open of `test.db' using driver `SQLite' successful. Layer name: test Geometry: Unknown (any) Feature Count: 1 Layer SRS WKT: (unknown) FID Column = rowid <-- see Geometry Column = GEOMETRY Then: $ ogr2ogr test2.db test.db -dsco spatialite=yes -f sqlite CreateSpatialIndex() error: a physical column named ROWID shadows the real ROWID Workaround : $ ogr2ogr test2.db test.db -dsco spatialite=yes -f sqlite -lco fid=my_rowid I think that Spatialite's validateRowid() fuction should be patched to check if the rowid column is not of type INTEGER PRIMARY KEY, if so that's acceptable, instead of just checking for rowid. CC'ing Sandro. Even On mardi 7 mars 2017 13:10:32 CET Martin Landa wrote: > Hi, > > recently I discovered strange behaviour when converting SQLite > database to Spatialite: > > ogr2ogr -f SQLite -dsco SPATIALITE=YES Export_vse.sdb Export_vse.db > ... > CreateSpatialIndex() error: a physical column named ROWID shadows the real > ROWID > > The output table contains rowid column even input table doesn't not > contain such column. It seems that this column is created by GDAL when > converting data into Spatialite DB, is it possible? > > Thanks, Martin -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
