[GRASS-dev] Proof of concept for more complete database access in
[was: Re: [GRASS-user] RE: Problem querying layers other than '1' in gi s.m]
mlennert at club.worldonline.be
Tue Oct 10 08:45:59 EDT 2006
Trevor Wiens wrote:
> On Tue, 26 Sep 2006 23:35:25 -0700
> Michael Barton wrote:
>> There seems to be some confusion in your statement about not liking GRASS as
>> a database and so switching to PostgreSQL. Perhaps what you really mean is
>> that you find dbf limiting for attribute management and prefer PostgreSQL.
> That is not what I said. What I said was that because I find attribute
> management awkward in GRASS I use PostGIS (the PostgreSQL equivalent
> to Oracle Spatial) for most vector work unless I need features in
> GRASS not found in PostGIS. In comparisons for operations such as
> overlays or point in polygon searches, GRASS is slightly faster than
> PostGIS, but in most cases the performance hit hasn't been significant
> and in the end, it is much faster to use PostGIS instead of GRASS
> because I don't have to import and export and reconnect attribute data.
> I get the results I want in a single query. I would like to have that
> same kind of control within GRASS.
Trying to take this a bit further, I have implemented a version of the
just posted d.vect.chart2
(http://grass.itc.it/pipermail/grass5/2006-October/026503.html) in a way
that it allows an arbitrary SQL query as source of the displayed data
(attached). This module (called d.vect.chart.sql for the purpose of this
proof of concept) contains an sql option which allows the user to use
any arbitrary sql query to define the data to be charted. This query has
to return the data in a certain order. A -s flag indicates that the
query also returns a sizecol and the user has to tell the module how
many data columns there are (this could probably be handled using the
SQL parser, but I didn't think it important at this stage).
So, you can run it as such
d.vect.chart.sql -s map=communes ncols=1 scale=0.0001 sql="select
t1.pop_2001, t2.pop_2001, t1.comcod from bel_espon143 as t1, commcen as
t2 where t1.comcod=t2.comcod order by t1.pop_2001 desc "
which shows that you can combine any table you want as long as the query
results correspond to the required format.
This module is only proof of concept and certainly needs improvements
and checks, but it works for me in its current state.
Trevor is this more in line with what you are looking for ? Maybe we
should think about reworking more modules to allow such an arbitrary sql
query at least as an option ?
> d.vect.chart.sql -h
Displays charts of GRASS vector data in the active frame on the
graphics monitor based on an arbitrary sql query
d.vect.chart.sql [-csr] map=name [type=string[,string,...]]
[layer=value] sql=string ncols=value [ctype=string] [size=value]
[scale=value] [ocolor=string] [colors=string[,string,...]]
-c Center the bar chart around a data point
-s SQL query contains size column
-r use square root of sizecol (to make area of pie, not diameter,
proportional to sizecol)
map Name of input vector map
layer Layer number
sql SQL statement retrieving the data in the following order:
data columns, [size column], key column
ncols Number of data columns (without size column)
ctype Chart type
size Size of chart (diameter for pie, total width for bar)
scale Scale for size (to get size in pixels)
ocolor Outline color
colors Colors used to fill charts
max_ref Maximum value used for bar plot reference
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6489 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20061010/74fdb5d4/d.vect.chart.sql.gtar
More information about the grass-dev