[GRASSLIST:9188] Re: sqlite driver - remarks and questions

David Finlayson david.p.finlayson at gmail.com
Tue Nov 22 16:32:03 EST 2005


On 11/22/05, Maciek Sieczka <werchowyna at epf.pl> wrote:

> NOTES AND QUESTIONS:
>
> 1. Importing with v.in.ogr to sqlite took over 37 minutes compared to
> about 41 seconds when using dbf driver with the same file. Could be
> faster?

db.select / db.execute is really slow when used with the sqlite
driver. In scripts (such as v.rast.stats) I have stripped out calls to
db.execute and replaced them with sql piped directly to sqlite3 with
large increases in speed. I don't know if this is the same issue that
you are facing with v.in.ogr (seems likely though).

> 3. But, the initial "Building spatial index" is as long for sqlite as
> for dbf, and occures each time d.what.vect is invoked. Is it
> unavoidable?

It would be nice if the spatial index where somehow stored in the db
for future access (it would need to be rebuilt only when changes to
the table were made?)

> 5. The sqlitebrowser, which has been mentioned on grass lists several
> times, is an _almost_ decent tool for viewing sqlite database, seems
> stable and fairly fast, but most of the needed editing tables
> functionality is lacking and there's no functionality for sorting data.
> I wouldn't depend on it for serious database handling. Does anybody know
> of something similar (sql GUI mixed with a kind of a spreadsheet) but
> more functional?

Can you issue a query in sqlite browser (I've only used sqlite3)?

SELECT cat, area  FROM attrtable ORDER BY cat;

David




More information about the grass-user mailing list