Re: [gdal-dev] sqlite -> spatialite (rowid)

> > So wondering if that makes sense in the SQLite driver to switch to > > AUTOINCREMENT FYI, I've just switched to declaring as AUTOINCREMENT (no option) -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing

Re: [gdal-dev] OGRGeometry::IsEmpty missing from trunk build

Even Rouault wrote: > On mardi 7 mars 2017 20:18:31 CET Gregory, Matthew wrote: > > Hi all, > > > > I was updating to the latest (python) Fiona version (1.7.4) and building > > GDAL trunk to supply as the gdal201.dll it requires. I'm on Windows 7 > > 64-bit, compiling GDAL with VC9 as 32-bit DLL.

Re: [gdal-dev] sqlite -> spatialite (rowid)

On Tue, 07 Mar 2017 20:41:26 +0100, Even Rouault wrote: I see that in the SQLite/Spatialite driver the primary key column is created just as INTEGER PRIMARY KEY, whereas in GeoPackage the standard requires that is INTEGER PRIMARY KEY AUTOINCREMENT. Hi Even, spatialite_gui and

Re: [gdal-dev] OGRGeometry::IsEmpty missing from trunk build

On mardi 7 mars 2017 20:18:31 CET Gregory, Matthew wrote: > Hi all, > > I was updating to the latest (python) Fiona version (1.7.4) and building > GDAL trunk to supply as the gdal201.dll it requires. I'm on Windows 7 > 64-bit, compiling GDAL with VC9 as 32-bit DLL. > > When I build a recent

[gdal-dev] OGRGeometry::IsEmpty missing from trunk build

Hi all, I was updating to the latest (python) Fiona version (1.7.4) and building GDAL trunk to supply as the gdal201.dll it requires. I'm on Windows 7 64-bit, compiling GDAL with VC9 as 32-bit DLL. When I build a recent commit of GDAL (Github 04105a9), I don't get a symbol for 'int

Re: [gdal-dev] sqlite -> spatialite (rowid)

I see that in the SQLite/Spatialite driver the primary key column is created just as INTEGER PRIMARY KEY, whereas in GeoPackage the standard requires that is INTEGER PRIMARY KEY AUTOINCREMENT. The SQLite doc mentions that AUTOINCREMENT is "a little slower" due to maintaining the sequence,

Re: [gdal-dev] sqlite -> spatialite (rowid)

Hi Sandro, I have only one detail to add: the MAX+1 policy that is used when AUTOINCREMENT is not declared can lead to re-use of previously used ROWIDs long before reaching the max possible value for an INTEGER 64bit. User just needs to delete the record with the highest ROWID. I trust that

[gdal-dev] Threading and Queue

Dear Users, Is the OGRCreateFeature, threaded ? Does it uses internal Queues ? Does OGR use threading and internal queues in General ? Sincerely, Ahmed ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

Re: [gdal-dev] sqlite -> spatialite (rowid)

On Tue, 7 Mar 2017 15:07:04 +, Rahkonen Jukka (MML) wrote: Hi, I have a slight feeling that there may be some trouble if attribute "ROWID" is INTEGER PRIMARY KEY but it does not AUTOINCREMENT and users do lot of deletes and inserts. Maybe not if the triggers in r-tree tables are clever

Re: [gdal-dev] sqlite -> spatialite (rowid)

On Tue, 07 Mar 2017 13:41:48 +0100, Even Rouault wrote: 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. Hi Even, very good point. SQLite

Re: [gdal-dev] sqlite -> spatialite (rowid)

On Tue, 7 Mar 2017 07:21:55 -0700 (MST), jratike80 wrote: Let's see what Sandro says but I do not believe it is acceptable. The r-tree spatial index is returning rowids to be used as keys to real data and if the main table has an ordinary attribute named as ROWID you can guess what will

Re: [gdal-dev] sqlite -> spatialite (rowid)

Hi Even, 2017-03-07 13:41 GMT+01:00 Even Rouault : [...] > FID Column = rowid <-- see right, this exactly my case. > Workaround : > $ ogr2ogr test2.db test.db -dsco spatialite=yes -f sqlite -lco fid=my_rowid Thanks, it works. Ma -- Martin Landa

Re: [gdal-dev] sqlite -> spatialite (rowid)

Hi, I have a slight feeling that there may be some trouble if attribute "ROWID" is INTEGER PRIMARY KEY but it does not AUTOINCREMENT and users do lot of deletes and inserts. Maybe not if the triggers in r-tree tables are clever enough. Just a slight feeling but perhaps you should test also

Re: [gdal-dev] sqlite -> spatialite (rowid)

Arg, it seems my email has been truncated in text version. Retrying... > Now I delete feature with rowid=3: > Let's see the state: $ ogrinfo test.db -al INFO: Open of `test.db' using driver `SQLite' successful. Layer name: test Geometry: Unknown (any) Feature Count: 2 Extent: (1.00,

Re: [gdal-dev] sqlite -> spatialite (rowid)

On mardi 7 mars 2017 07:21:55 CET jratike80 wrote: > Even Rouault-2 wrote > > > 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

Re: [gdal-dev] sqlite -> spatialite (rowid)

Even Rouault-2 wrote > 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. Let's see what Sandro says but I do not believe it is

Re: [gdal-dev] sqlite -> spatialite (rowid)

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

[gdal-dev] sqlite -> spatialite (rowid)

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

Re: [gdal-dev] WFS driver and GML application schema

On mardi 7 mars 2017 09:57:26 CET Rahkonen Jukka (MML) wrote: > Hi, > > What if a WFS server is returning GML that has complex schema, does GDAL > know to open the response as GML application schema data automatically or > with some open option? I ask because I can see "succeeds as GML" in the

Re: [gdal-dev] Overcome attribute name limitation in shapefiles

Even, > What is this software that produces this sidecar CSV-like format ? It is a traffic demand and simulation software called PTV-VISUM (http://vision-traffic.ptvgroup.com/en-uk/products/ptv-visum/) > Could you show examples of such datasets ?

[gdal-dev] WFS driver and GML application schema

Hi, What if a WFS server is returning GML that has complex schema, does GDAL know to open the response as GML application schema data automatically or with some open option? I ask because I can see "succeeds as GML" in the debug log: HTTP:

Re: [gdal-dev] Overcome attribute name limitation in shapefiles

On mardi 7 mars 2017 09:17:50 CET Felix Obermaier wrote: > Peter, > > why would it cease to respect the dBaseIV Standard? I’m not proposing a > change regarding the dBase format but an additional file that gives > additional information the data in the attribute column. If you don’t > supply that

Re: [gdal-dev] Overcome attribute name limitation in shapefiles

Peter, why would it cease to respect the dBaseIV Standard? I’m not proposing a change regarding the dBase format but an additional file that gives additional information the data in the attribute column. If you don’t supply that file you don’t have the additinal information, but you still can