> > 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
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.
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 spatialite-tool
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 comm
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 OGRGeom
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, bu
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 tri
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
https://lists.osgeo.org/mailman/listinfo/gdal
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 eno
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 already
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
happen.
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
http://geo.fsv.cvut.cz/gwiki/Landa
http://gism
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 case
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, 2
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 S
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 ac
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'
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 ta
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
>
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 ?
http://download.ivv-aachen.de/webdaten/ptv-vi
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:
Fetch(https://opaskartta.turku.fi/TeklaOGCWeb/WFS.as
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
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 a
23 matches
Mail list logo