[GRASS-dev] Re: Proof of concept for more complete database access in GRASS module [was: Re: [GRASS-user] RE: Problem querying layers other than '1' in gi s.m]

[Moritz Lennert]

Trevor Wiens wrote:
> On Tue, 10 Oct 2006 16:53:26 +0200
> Moritz Lennert wrote:
> 
>> Trevor Wiens wrote:
>>
>>> I wonder now how many steps it takes to recreate your arbitrary query
>>> graph with 'layers' and I wonder about performance differences between
>>> the two.
>> I'm not sure you can handle this via layers. Currently you have to do 
>> the following (untested):
>>
>> echo "create view temp as select t1.pop_2001 as pop1, t2.pop_2001 as 
>> pop2, t1.comcod from bel_espon143 as t1, commcen as t2 where 
>> t1.comcod=t2.comcod order by t1.pop_2001 desc" | db.execute
>>
>> v.db.connect -o map=communes table=temp key=comcod
>>
>> d.vect.chart map=communes scale=0.0001 columns=pop1 sizecol=pop2
>>
>> v.db.connect -o map=communes table=original_table key=keycolumn
>>
>> echo "drop view temp" | db.execute
>>
>> So, in order to get back to the exact previous situation four extra 
>> steps of creating the view, linking to the view, linking back to the 
>> original data table and erasing the view.
>>
>> Moritz
> 
> That is what I thought. Although the concept of layers probably sounded
> good at the time, my guess is that once implemented in all modules,
> arbitrary queries will prove to be much more flexible and
> operationally quicker (but perhaps computationally slower).
> 
> I should add however, in defence of layers, that for users without
> knowledge of SQL, arbitrary queries might in fact be much more
> difficult to use than layers. On the other hand, if one is serious about
> GIS at some point one has to get serious about attribute management
> which means moving beyond flat files anyway. So... I suppose arbitrary
> queries would push people to learning things that are useful later on.
> Since layers are counter-intuitive and require learning anyway....

I don't want to break off another debate on layers, here, but I don't 
think that the issue here really are the layers. It is the use of sql 
within the module. As was stated several times before, you don't even 
have to think about layers, if you don't want to in GRASS.
However, some people have found applications of layers which they found 
very useful, and I doubt that all of the can be solved by arbitrary SQL 
queries, as some of them concern the underlying geometry, and not only 
the attributes.

But I'd rather think about the best way to implement arbitrary queries 
in modules than continue this debate ;-)

Moritz