On Mon, 17 Jun 2019 09:46:20 +1200, Mike Taves wrote:
I'm not sure how SpatiaLite has implemented ST_Length,
but could be worth checking into.
Hi Mike,
SpatiaLite started supporting geodesic distances
about ten years ago, and two different methods
were implemented as internal C functions:
1.
On Thu, 06 Sep 2018 09:11:35 +0200, Even Rouault wrote:
On mercredi 5 septembre 2018 16:48:52 CEST Newcomb, Doug wrote:
Hi Folks,
I was in a meeting today and the question came up:
What is the maximum size of a vector data layer in a geopackage
database? a
raster layer?
No limits other than
On Mon, 18 Sep 2017 12:25:47 +1000, Nik Sands wrote:
Hi GDAL devs,
What is the correct way in GDAL/OGR to release locks on the layer (in
this case the SQLite tables in a geopackage) so that the layer can be
deleted from the data source?
My issue is that after writing new features to a layer, I
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 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.
On Mon, 25 Jan 2016 15:20:13 +0530, Gane R wrote:
I got a source of sqlite3 from amalgation. I compiled on linux to get
a static lib say libsqlite3.a
Hi Gene,
starting from the amalgamation sources definitely isn't the best
option,
because this way libsqlite3 will not be correctly installe
Hi Even,
I casually noticed that the ./configure script fails to correctly
identify libfreexl on Windows when using the MinGW/MSYS compiler.
this error message is always returned even when the most recent
version of libfreexl is correctly installed:
"freexl too old. Needs freexl >= 1.0"
the cau
On Thu, 10 Dec 2015 18:22:09 +, kelly elton wrote:
I'm just trying to figure out how to turn on SQlite/Spatialite shared
cache in the latest stable version 2.0.1
Before I would just call SPLite3_enable_shared_cache but apparently
that's been deprecated and doesn't exist anymore.(as well as
S
On Fri, 4 Dec 2015 14:29:47 +0100, Even Rouault wrote:
So it looks very much like "x = NULL" is not "normal" SQL at all.
just a may be useful comment about this topic
accordingly to SQL standard syntax rules NULL should never be
confused with any other ordinary value; it's instead a special
m
On Tue, 19 May 2015 11:25:27 +0200, Even Rouault wrote:
Debian Sid, might be a platform specific issue?
https://bugs.debian.org/785091
few technical details useful to understand better:
a) starting since November 2013 it become definitely clear
that the older self-registration mechanism ba
Jukka, Pepjin and Even,
AFAIK there is not a clearly "better" way to store DATE values
(TIME, DATETIME, TIMESTAMP and alike) in a SQLite DB-file.
* SQLite practically ignores any datatype definition placed
at the column level; real datatypes are bound to each
single cell, and can be one bet
On Mon, 26 Jan 2015 18:47:25 +0100, Even Rouault wrote:
Hi,
This is a call for discussion on the new "RFC 52 - Strict OGR SQL
quoting",
based on an older ticket.
http://trac.osgeo.org/gdal/wiki/rfc52_strict_sql_quoting
Summary :
This RFC proposes that OGR SQL enforces strict quoting rules f
On Tue, 30 Sep 2014 12:49:50 +0200, Even Rouault wrote:
Jukka, Sandro,
Upon investigation, the T suffix was added by the OGR SQLite driver.
I've
removed it in trunk for now per
http://trac.osgeo.org/gdal/ticket/5672
Even, Jukka,
the patch #5672 seems to definitively resolve this issue.
On Mon, 29 Sep 2014 21:44:30 + (UTC), Jukka Rahkonen wrote:
Hi,
I noticed http://trac.osgeo.org/gdal/changeset/27768 and by looking
at the
different date and time formats I remembered that I have just
received some
data where dates were expressed as "2014-09-27T" which lead to some
troubl
On Mon, 9 Jun 2014 07:31:05 + (UTC), Jukka Rahkonen wrote:
Perhaps this has something to do with different SQLite versions
included in
GDAL and Spatialite-gui. My GDAL is v.2.0 Win-64 build from
gisinternals.
This kind of behaviour is nasty when planning to build well optimized
and
index
On Mon, 10 Mar 2014 12:23:22 + (UTC), Jukka Rahkonen wrote:
Hi,
I saw a blog about using prepared statements for bulk inserts into
SQLite
http://blog.quibb.org/2010/08/fast-bulk-inserts-into-sqlite/
Results show that with prepared statements the inserts/second rate in
the
test were at l
On Tue, 4 Mar 2014 23:13:51 +1100, Nik Sands wrote:
The conversion process is a little slow for large data sets
Hi Nik,
SQLite is a transactional DBMS and consequently your
approach to transaction handling has a very strong
impact on write performances.
just as a quick and dirty rule-of-the-
Hi all,
just yo better clarify some relevant details:
a Shapefile can legitimately contain one the following shapes:
Point, PolyLine, Polygon and MultiPoint; and there are further
shape-codes intended to support extended XYZ or XYM dimensions,
such as PointZ and PolyLineM
please note: according
On Mon, 17 Feb 2014 16:14:39 +0100, Even Rouault wrote:
Jukka,
I highly suspect that the ALTER TABLE must imply a rewriting of the
file by
spatialite/spatialite-gui, and when doing so, it doesn't preserve the
"application id" (4 bytes in the header of sqlite file), that
geopackage
specificati
On Thu, 10 May 2012 06:49:07 + (UTC), Jukka Rahkonen wrote:
Is there a way for me as a non-programmer to check if the components
used for
Rasterlite conversion in the Windows 32-bit binaries from
gisinternals.com
have been built with or without
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1
On Wed, 9 May 2012 19:50:15 + (UTC), Jukka Rahkonen wrote:
However, the Rasterlite file size has probably been
around 4 gigabytes when the error occurred. Did I meet some file size
limit or tile count limit of the Rasterlite driver?
Hi Jukka,
on any platform there is an intrinsic physical
HI Frank and Even,
I confirm that Even is absolutely right: using the "amalgamation"
on Linux is strongly discouraged, and may pose several problems
if not properly handled. Just few technical clarifications:
a) libspatialite expects to link an external lisqlite3; there
is absolutely nothing ex
On Tue, 13 Dec 2011 11:40:01 +0100, Even Rouault wrote
> Having sample data to add regression will be needed.
>
please see the attached GML-Topo sample
> What do you think about the xlink1.gml that I mention in the ticket
> ? Is it valid to have xlink:href to other documents ?
>
I've asked t
On Sun, 11 Dec 2011 16:33:58 +0100, Even Rouault wrote
> Hi Sandro,
>
> I'm OK with your patch. I guess that the name of the
> GML_SQLITE_CACHE_MB config option must come from your work with your
> previous GML patch, but I'd suggest to rename it to OGR_SQLITE_CACHE
> as it is more general. Are
26 matches
Mail list logo
