[GRASS-user] getting from DBF to SQLite
Michael Barton
Michael.Barton at asu.edu
Thu Feb 14 07:47:45 PST 2013
This and especially portability is why I argued--unsuccessfully--for a separate sqlite DB for each vector file, even if it is inefficient.
Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton
On Feb 14, 2013, at 5:55 AM, grass-user-request at lists.osgeo.org<mailto:grass-user-request at lists.osgeo.org> wrote:
From: Hamish <hamish_b at yahoo.com<mailto:hamish_b at yahoo.com>>
Subject: Re: [GRASS-user] getting from DBF to SQLite
Date: February 13, 2013 4:50:15 PM MST
To: GRASS user list <grass-user at lists.osgeo.org<mailto:grass-user at lists.osgeo.org>>
Richard wrote:
Is it is possible to set a single SQLite database
for the entire GRASS GIS database or each mapset requires
its own sqlite db file?
organize your system as you like, but be sure to ask yourself what
happens to portability with 32bit machines and/or filesystems when the overall DB file gets to be larger than 2gb or 4gb in size.
Even per-mapset sqlite DBs worry me a bit for that, not to mention
the damage-fallout from a bad HD sector or accidental `rm` and
ease of moving stuff to another mapset/ system by hand.
Hamish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130214/8d06ebb7/attachment-0001.html>
More information about the grass-user
mailing list