sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64

Michael Barton michael.barton at asu.edu
Thu Mar 5 20:25:39 EST 2009



On Mar 5, 2009, at 5:44 PM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Thu, 5 Mar 2009 19:04:46 +0100
> From: Markus Neteler <neteler at osgeo.org>
> Subject: Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and
> 	grass64
> To: Moritz Lennert <mlennert at club.worldonline.be>
> Cc: GRASS developers list <grass-dev at lists.osgeo.org>
> Message-ID:
> 	<86782b610903051004n5601199ax269f60f1949c6843 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Mar 5, 2009 at 4:38 PM, Moritz Lennert
> <mlennert at club.worldonline.be> wrote:
>> On 05/03/09 10:43, Markus Neteler wrote:
> ..
>>> Suggestion:
>>> make SQLite as default DBMS driver in devel_branch6 (alias GRASS  
>>> 6.5).
>>> Since today, in 2009, the driver has received a lot of testing, is
>>> definitely superiour to DBF (where we regularly get complaints).
>>
>> +1
>>
>>>
>>> If allowing one file per map isn't too hard to implement as optional
>>> feature it might be a (last) requirement to make it the default  
>>> driver.
>>
>> I think that for the same arguments as those brought forward by  
>> Glynn above,
>> we should make single file db the default. Anyone who really needs  
>> it can
>> easily create a per-vector db with v.db.connect.
>
> Remember that Glynn mentioned that joins won't work in this case.
>
>> Concerning the need to be able to easily backup/share, I think we  
>> definitely
>> need some module which isolates and exports a series of chosen maps  
>> in a new
>> temporary mapset with a local sqlite db file, copies the chosen  
>> maps into
>> this temp mapset and then creates a tarball (or zip or whatever)  
>> with the
>> basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND  
>> files) and
>> the temp mapset. Shouldn't be too hard to wip up, or ?
>
> Essentially a v.pack/v.unpack, right?
>
> Markus

I like the idea of sqlite. But I also favor 1 db per vector.  
Portability is important. Think about the issues with ArcGIS (a real  
pain).

Joins between different vectors indeed won't work if there is one db  
per vector. But how many times does one want to join the attribute  
table of one vector with the attribute table of a different vector?  
I'm sure that there could be cases, but I'd warrant that there aren't  
many. More often one wants to join multiple tables for the SAME  
vector. In this case, you would have multiple tables for a single  
vector db.

Michael





More information about the grass-dev mailing list