Re: [GRASS-dev] GRASS performance references

[Rasmus Lundgaard Borgstrøm]

Hi Peter

Thanks for supplying your info and links, looks very interesting and relevant.

"What kind of quantitative measurements and performance metrics would you 
consider useful for GRASS GIS ?"
Basically measurements of volume and speed of processing certain image amounts; 
 
E.g. GRASS GIS loaded, processed (e.g. standard classification) and exported an 
10 GB RapidEye image mosaic in XX minutes/hours. 
Ideally this flow should be compared with identical processed performed in 
closed source SW, as ENVI, Erdas, ArcGIS and other Open Source SW. 

I would also like to identify any bottlenecks/showstoppers with regards to data 
volume. 

I have seen something similar in the CASCADOSS project; 
http://www.cascadoss.eu/en/index.php?option=com_content&task=view&id=14&Itemid=14
But not exactly what I wanted to showcase and use for 
documentation/justification of our setup. 

Kind regards,
Rasmus

-Original Message-
From: Peter Löwe [mailto:plo...@gfz-potsdam.de] 
Sent: 14 August 2012 17:10
To: Rasmus Lundgaard Borgstrøm
Subject: Re: [GRASS-dev] GRASS performance references

 > In this respect, I am trying to identify references about GRASS GIS  > 
 > performance, that would allow me to state any quantitative measures of the  
 > > expected performance (data volume, processing speed etc.). Thus any links 
 > to  > documented work on handling large and multiple raster files in GRASS 
 > GIS  > would be appreciated.
 >

Hello Rasmus,

regarding your question on GRASS-dev concerning quantitative measures for large 
and multiple raster processing in GRASS:

Previous work at RapidEye (http://www.rapideye.com/) involved large scale 
satellite image processing with GRASS, also using multiple scenes. 
Until now only bits of this has been published: 
http://2010.foss4g.org/presentations_show.php?id=3678
As my current work involves GRASS-based workflows on a HPC cluster, I would 
also be interested if the topic of quantitative measures would receive more 
attention.

What kind of quantitative measurements and performance metrics would you 
consider useful for GRASS GIS ?

Kind regards,
Peter

PS: Here are some links to presentions regarding HPC/GRASS:
http://www.wgug.org/images/stories/materialy/2011/pl_rendering_virtual_globes_presentation.pdf
http://presentations.copernicus.org/EGU2012-4364_presentation.pdf







--
--
Dr. Peter Löwe
Helmholtz-Zentrum Potsdam
Deutsches GeoForschungsZentrum - GFZ
Telegraphenberg A20
D-14473 Potsdam
Germany
Tel: +49-331-288-2338
Fax: +49-331-288-1703
--



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] WinGRASS 6.4.3/6.5 binary???

[Hamish]

Michael:
> The current dev versions are so much better than 6.4.2 stable that I'd
> prefer the students to experience them rather than the dated and more
> buggy stable version.

I would challenge the assertion that 6.4.2 is dated and buggy in any
serious manner. It is your call of course, but from my POV I would not put
students (or new users in general) in front of untested development
versions, they never know if when something goes wrong if it is them or
the software, or if the software is just "too hard".

The only critical bug I know of that is fixed in svn is that the addon
downloads from Martin's server are not working on WinGrass, which is
apparently fixed in svn but it would be really really nice if a 6.4.2-3
binary installer was issued with just that fix added. (not sure, did
something change server-side?)

are there other specific issues?


best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Empty default answer

[Anna Kratochvílová]

On Tue, Aug 14, 2012 at 2:52 PM, Luca Delucchi  wrote:
> Is it correct leave empty a default answer in a module?
> An example is in r.out.pov with zmod or objmod option

According to programming manual 'answer' is not required. Also see
[1]. Maybe I am missing something but I can't see the options zmod and
objmod for that module.

Anna

[1] 
http://grass.osgeo.org/programming7/gislib.html#Answer_member_of_the_Flag_and_Option_structures


>
> Thanks
> Luca
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] i.atcorr @ GRASS6.4 using RapidEye: strange output

[Peter Löwe]

Hi,

I'm reporting again on the mixed performance of i.atcorr for RapidEye satellite 
data in GRASS6.4.2 on SuSE.

In a test case RapidEye satellite data for the Spearfish,SD demo site is used.

Rapideye data comes in 16bit. 

The value ranges (digital numbers) for the first three bands are:
red: [1286 - 58603]
green: [2464 - 54248]
blue: [4069-56975]

So two variants were tried:

Variant A) Using r.rescale to scale the data down to 8 bit

Example [red band]:
i.atcorr iimg=spearfish_3.255.rad iscl=0,255 oscl=0,255 
icnd=re_20100509_3.atcorr_20120814 oimg=spearfish_3.255.rad.atcorr_20120814 --o

The output map consists mostly of zeroes and NULLs with a few 1s and 2s for 
both red and blue band. "i.atcorr-ing" the green band returns just NULLs.

Variant B) i.atcorrs "iscl"-option is used to provide the 16bit data range for 
each band.

Example [red band]:
i.atcorr iimg=spearfish_3 iscl=1286,58603 oscl=0,255 
icnd=re_20100509_3.atcorr_20120814 
oimg=spearfish_3.atcorr_test1_1286-58603_0-255 --o

Now the results for the red band seem reasonable, the results for the blue band 
look like a "salt and pepper" pattern and the green band again goes NULL.

Ideas, anyone ? Does this kind of behaviour also occur for other sensors ?

Best,
Peter
 


-- 
Dr. Peter Löwe






___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #151: make documentation be full text searchable: use sphinx

[GRASS GIS]

#151: make documentation be full text searchable: use sphinx
-+--
 Reporter:  timmie   |   Owner:  epatton
 Type:  enhancement  |  Status:  assigned   
 Priority:  major|   Milestone:  7.0.0  
Component:  Website  | Version:  unspecified
 Keywords:   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:25 glynn]:
 > Replying to [comment:17 lucadelu]:
 > > In r52658 I added a first implementation of reStructuredText
 documentation for grass7. It uses the --rest-description flag and the
 [http://johnmacfarlane.net/pandoc/ pandoc] software.
 > I don't see what problem this is trying to solve.

 Besides a more modern look, it offers an included search engine for
 the manual which even works offline in local GRASS GIS installations.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #742: v.coregister / v.align : A module to translate and rotate a point cloud to best match one another

[GRASS GIS]

#742: v.coregister / v.align : A module to translate and rotate a point cloud to
best match one another
-+--
 Reporter:  stevensj |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  unspecified  
 Keywords:  lidar, point, cloud  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by neteler):

  * milestone:  6.5.0 => 7.0.0


Comment:

 In GRASS 7, there is v.rectify which could do the job when you have
 3D control points:
 http://grass.osgeo.org/grass70/manuals/html70_user/v.rectify.html

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Empty default answer

[Luca Delucchi]

Is it correct leave empty a default answer in a module?
An example is in r.out.pov with zmod or objmod option

Thanks
Luca
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #151: make documentation be full text searchable: use sphinx

[GRASS GIS]

#151: make documentation be full text searchable: use sphinx
-+--
 Reporter:  timmie   |   Owner:  epatton
 Type:  enhancement  |  Status:  assigned   
 Priority:  major|   Milestone:  7.0.0  
Component:  Website  | Version:  unspecified
 Keywords:   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:17 lucadelu]:
 > In r52658 I added a first implementation of reStructuredText
 documentation for grass7. It uses the --rest-description flag and the
 [http://johnmacfarlane.net/pandoc/ pandoc] software.
 I don't see what problem this is trying to solve.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Speed map display in wxGUI on bigger monitors

[Glynn Clements]

Markus Neteler wrote:

> when working with the wxGUI on bigger monitors, it is rather slow
> when it comes to map display.
> Looking into the /tmp/ directory, I find fairly huge files which are
> generated and then combined for display.
> It is getting even worse when using GRASS over network.
> 
> Question: why the uncompressed PNM/PPM format used by g.pnmcomp?

The original reason was that Tk doesn't support PNG.

That isn't relevant to the wxPython GUI. But the wxPython GUI should
really be doing its own compositing rather than relying upon
g.pnmcomp.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1696: Error message v.db.dropcol (Add-On Path)

[GRASS GIS]

#1696: Error message v.db.dropcol (Add-On Path)
---+
 Reporter:  jradinger  |   Owner:  hamish 
 Type:  defect |  Status:  assigned   
 Priority:  normal |   Milestone:  6.4.3  
Component:  Shell Scripts  | Version:  unspecified
 Keywords: |Platform:  Unspecified
  Cpu:  All|  
---+
Changes (by hamish):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => hamish
  * status:  new => assigned


Comment:

 right, this is a sibling of #1683, sorry I haven't been able to get to all
 of them yet. Further review of the GUI's method of setting the ADDON
 environment variable is needed too, but the scripts should be robust
 enough to deal with it regardless.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1683: error message v.db.addcol

[GRASS GIS]

#1683: error message v.db.addcol
---+
 Reporter:  jradinger  |   Owner:  hamish  
 Type:  defect |  Status:  assigned
 Priority:  major  |   Milestone:  6.4.3   
Component:  Shell Scripts  | Version:  svn-develbranch6
 Keywords:  v.db.addcol|Platform:  All 
  Cpu:  Unspecified|  
---+
Changes (by hamish):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => hamish
  * status:  new => assigned


Comment:

 (see comment:5)

 what does `g.gisenv` by itself on the command line show?

 does you mapset have a space in it? (AFAIU you should have gotten an error
 when you tried)


 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Warning in the Terminal when closing the GRASS GUI

[Markus Neteler]

On Tue, Aug 14, 2012 at 12:15 PM, Johannes Radinger
 wrote:
> Hi,
>
> it is not a problem at all but there are several similar warning messages
> printed in
> the GRASS terminal window after closing the GUI. Here the terminal output
> from launching
> GRASS till closing (clicking on x) the GUI window:
>
> radinger@grassgis:~$ grass65
> Cleaning up temporary files ...
> Starting GRASS ...
...
> Welcome to GRASS 6.5.svn (2012)
...
> When ready to quit enter:exit
>
> GRASS 6.5.svn (Cele_location):~ >
...
> (python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
> doesn't believe we're it's parent.
>
> I am working with GRASS6.5SVN r52671 on Ubuntu 12.04 with python version
> 2.7.3.
> I don't know if it is a known problem or if it is serious/important at all.
> If need I can file a ticket.

There seems to be a related ticket:
http://trac.wxwidgets.org/ticket/14292

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1683: error message v.db.addcol (was: error message v.add.col on MacOSX)

[GRASS GIS]

#1683: error message v.db.addcol
---+
 Reporter:  jradinger  |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.3
Component:  Shell Scripts  | Version:  svn-develbranch6 
 Keywords:  v.db.addcol|Platform:  All  
  Cpu:  Unspecified|  
---+

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Warning in the Terminal when closing the GRASS GUI

[Johannes Radinger]

Hi,

it is not a problem at all but there are several similar warning messages
printed in
the GRASS terminal window after closing the GUI. Here the terminal output
from launching
GRASS till closing (clicking on x) the GUI window:

radinger@grassgis:~$ grass65
Cleaning up temporary files ...
Starting GRASS ...

__  ___   _____
 / / __ \/   | / ___/ ___/   / /  _/ ___/
/ / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
   / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
   \/_/ |_/_/  |_///   \/___///

Welcome to GRASS 6.5.svn (2012)
GRASS homepage:  http://grass.osgeo.org/
This version running thru:   Bash Shell (/bin/bash)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
If required, restart the GUI with:   g.gui wxpython
When ready to quit enter:exit

GRASS 6.5.svn (Cele_location):~ >
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.
(python:11076): LIBDBUSMENU-GLIB-WARNING **: Trying to remove a child that
doesn't believe we're it's parent.

I am working with GRASS6.5SVN r52671 on Ubuntu 12.04 with python version
2.7.3.
I don't know if it is a known problem or if it is serious/important at all.
If need I can file a ticket.

Best regards,
Johannes
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1683: error message v.add.col on MacOSX

[GRASS GIS]

#1683: error message v.add.col on MacOSX
---+
 Reporter:  jradinger  |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.3
Component:  Shell Scripts  | Version:  svn-develbranch6 
 Keywords:  v.db.addcol|Platform:  All  
  Cpu:  Unspecified|  
---+

Comment(by jradinger):

 I tried again with the first example (streams@test). No problems occured.
 Anyway another
 mapset still produces error messages:

 {{{

 (Tue Aug 14 12:46:01 2012)
 v.db.addcol map=sender_point@FIDIMO_Cele columns=testcol DOUBLE
 /usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval:
 FIDIMO_Cele: not found
 (Tue Aug 14 12:46:02 2012) Command finished (1 sec)
 }}}

 And here the extended output:

 {{{
 (Tue Aug 14 12:48:12 2012)
 v.db.addcol map=sender_point@FIDIMO_Cele columns=testcol DOUBLE
 + [ -z /usr/local/grass-6.5.svn ]
 + [ map=sender_point@FIDIMO_Cele != @ARGS_PARSED@ ]
 + basename /usr/local/grass-6.5.svn/scripts/v.db.addcol
 + CMDLINE=v.db.addcol
 + CMDLINE=v.db.addcol "map=sender_point@FIDIMO_Cele"
 + CMDLINE=v.db.addcol "map=sender_point@FIDIMO_Cele"
 "columns=testcol DOUBLE"
 + export CMDLINE
 + exec g.parser /usr/local/grass-6.5.svn/scripts/v.db.addcol
 map=sender_point@FIDIMO_Cele columns=testcol DOUBLE
 + [ -z /usr/local/grass-6.5.svn ]
 + [ @ARGS_PARSED@ != @ARGS_PARSED@ ]
 + basename /usr/local/grass-6.5.svn/scripts/v.db.addcol
 + PROG=v.db.addcol
 + which awk
 + [ ! -x /usr/bin/awk ]
 + unset LC_ALL
 + LC_NUMERIC=C
 + export LC_NUMERIC
 + g.gisenv get=MAPSET
 + eval FIDIMO_Cele
 + FIDIMO_Cele
 /usr/local/grass-6.5.svn/scripts/v.db.addcol: 1: eval:
 FIDIMO_Cele: not found
 + g.findfile element=vector file=sender_point@FIDIMO_Cele
 mapset=
 + eval name='sender_point@FIDIMO_Cele' mapset='FIDIMO_Cele'
 fullname='sender_point@FIDIMO_Cele' file='/home/radinger/Doc
 uments/GRASS_locations/Cele_location/FIDIMO_Cele/vector/send
 er_point'
 + name=sender_point@FIDIMO_Cele mapset=FIDIMO_Cele
 fullname=sender_point@FIDIMO_Cele file=/home/radinger/Docume
 nts/GRASS_locations/Cele_location/FIDIMO_Cele/vector/sender_
 point
 + [ ! /home/radinger/Documents/GRASS_locations/Cele_location
 /FIDIMO_Cele/vector/sender_point ]
 + v.db.connect sender_point@FIDIMO_Cele -gl layer=1 fs=|
 + cut -f2 -d|
 + table=sender_point
 + [ -z sender_point ]
 + cut -f4 -d|
 + v.db.connect sender_point@FIDIMO_Cele -gl fs=| layer=1
 + database=/home/radinger/Documents/GRASS_locations/Cele_loc
 ation/FIDIMO_Cele/sqlite.db
 + cut -f5 -d|
 + v.db.connect sender_point@FIDIMO_Cele -gl fs=| layer=1
 + driver=sqlite
 + awk -F, {print NF}
 + echo testcol DOUBLE
 + colnum=1
 + n=1
 + [ 1 -le 1 ]
 + cut -d, -f1
 + echo testcol DOUBLE
 + col=testcol DOUBLE
 + [ -z testcol DOUBLE ]
 + db.execute database=/home/radinger/Documents/GRASS_locatio
 ns/Cele_location/FIDIMO_Cele/sqlite.db driver=sqlite
 + echo ALTER TABLE sender_point ADD COLUMN testcol DOUBLE
 + [ 0 -eq 1 ]
 + expr 1 + 1
 + n=2
 + [ 2 -le 1 ]
 + v.support sender_point@FIDIMO_Cele cmdhist=v.db.addcol
 "map=sender_point@FIDIMO_Cele" "columns=testcol DOUBLE"
 + exit 0
 (Tue Aug 14 12:48:13 2012) Command finished (1 sec)
 }}}

 So far as I can see there is no whitespace in the mapset.
 Tested on Ubuntu 12.04 with Grass6-devel r52671. This might
 be related to ticket #1696.

 /johannes

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #1696: Error message v.db.dropcol (Add-On Path)

[GRASS GIS]

#1696: Error message v.db.dropcol (Add-On Path)
---+
 Reporter:  jradinger  |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  normal |   Milestone:  6.4.3
Component:  Shell Scripts  | Version:  unspecified  
 Keywords: |Platform:  Unspecified  
  Cpu:  All|  
---+
 Hi,

 when I try to drop a column from a table I get following error message
 although the table is modified correctly:


 {{{
 (Tue Aug 14 12:47:30 2012)
 v.db.dropcol map=sender_point@FIDIMO_Cele column=testcol
 /usr/local/grass-6.5.svn/scripts/v.db.dropcol: 1: eval: adin
 ger/05_GRASS/GRASS_Scripts=/home/radinger/U_Radinger/05_GRAS
 S/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo: not
 found
 /usr/local/grass-6.5.svn/scripts/v.db.dropcol: 1: eval: /r.r
 dfilter=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Scr
 ipt/fidimo for grass 6.x/r.fidimo: not found
 (Tue Aug 14 12:47:31 2012) Command finished (1 sec)
 }}}

 and here an extended output with the -x flag:

 {{{

 (Tue Aug 14 13:00:50 2012)
 v.db.dropcol map=sender_point@FIDIMO_Cele column=testcol
 + [ -z /usr/local/grass-6.5.svn ]
 + [ map=sender_point@FIDIMO_Cele != @ARGS_PARSED@ ]
 + basename /usr/local/grass-6.5.svn/scripts/v.db.dropcol
 + CMDLINE=v.db.dropcol
 + CMDLINE=v.db.dropcol "map=sender_point@FIDIMO_Cele"
 + CMDLINE=v.db.dropcol "map=sender_point@FIDIMO_Cele"
 "column=testcol"
 + export CMDLINE
 + exec g.parser
 /usr/local/grass-6.5.svn/scripts/v.db.dropcol
 map=sender_point@FIDIMO_Cele column=testcol
 + [ -z /usr/local/grass-6.5.svn ]
 + [ @ARGS_PARSED@ != @ARGS_PARSED@ ]
 + basename /usr/local/grass-6.5.svn/scripts/v.db.dropcol
 + PROG=v.db.dropcol
 + g.tempfile pid=10834
 + TEMPFILE=/home/radinger/Documents/GRASS_locations/Cele_loc
 ation/FIDIMO_Cele/.tmp/grassgis/10834.0
 + [ 0 -ne 0 ]
 + [ -z /home/radinger/Documents/GRASS_locations/Cele_locatio
 n/FIDIMO_Cele/.tmp/grassgis/10834.0 ]
 + trap exitprocedure 2 3 15
 + g.gisenv
 + eval GISDBASE='/home/radinger/Documents/GRASS_locations';
 LOCATION_NAME='Cele_location'; MAPSET='FIDIMO_Cele'; ADDON_P
 ATH='/home/radinger/.grass6/addons:/home/radinger/.grass6/ad
 dons:/home/radinger/.grass6/addons:/home/radinger/.grass6/ad
 dons:/home/radinger/U_Radinger/05_GRASS/GRASS_Scripts:/home/
 radinger/U_R'; adinger/05_GRASS/GRASS_Scripts='/home/radinge
 r/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass
 6.x/r.fidimo'; /r.rdfilter='/home/radinger/U_Radinger/05_GRA
 SS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo';
 GRASS_GUI='wxpython';
 + GISDBASE=/home/radinger/Documents/GRASS_locations
 + LOCATION_NAME=Cele_location
 + MAPSET=FIDIMO_Cele
 + ADDON_PATH=/home/radinger/.grass6/addons:/home/radinger/.g
 rass6/addons:/home/radinger/.grass6/addons:/home/radinger/.g
 rass6/addons:/home/radinger/U_Radinger/05_GRASS/GRASS_Script
 s:/home/radinger/U_R
 + adinger/05_GRASS/GRASS_Scripts=/home/radinger/U_Radinger/0
 5_GRASS/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo
 /usr/local/grass-6.5.svn/scripts/v.db.dropcol: 1: eval: adin
 ger/05_GRASS/GRASS_Scripts=/home/radinger/U_Radinger/05_GRAS
 S/FIDIMO/FIDIMO_Script/fidimo for grass 6.x/r.fidimo: not
 found
 + /r.rdfilter=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDI
 MO_Script/fidimo for grass 6.x/r.fidimo
 /usr/local/grass-6.5.svn/scripts/v.db.dropcol: 1: eval: /r.r
 dfilter=/home/radinger/U_Radinger/05_GRASS/FIDIMO/FIDIMO_Scr
 ipt/fidimo for grass 6.x/r.fidimo: not found
 + GRASS_GUI=wxpython
 + : /usr/local/grass-6.5.svn
 /home/radinger/Documents/GRASS_locations Cele_location
 FIDIMO_Cele
 + g.findfile element=vector file=sender_point@FIDIMO_Cele
 mapset=FIDIMO_Cele
 + eval name='sender_point@FIDIMO_Cele' mapset='FIDIMO_Cele'
 fullname='sender_point@FIDIMO_Cele' file='/home/radinger/Doc
 uments/GRASS_locations/Cele_location/FIDIMO_Cele/vector/send
 er_point'
 + name=sender_point@FIDIMO_Cele mapset=FIDIMO_Cele
 fullname=sender_point@FIDIMO_Cele file=/home/radinger/Docume
 nts/GRASS_locations/Cele_location/FIDIMO_Cele/vector/sender_
 point
 + [ ! /home/radinger/Documents/GRASS_locations/Cele_location
 /FIDIMO_Cele/vector/sender_point ]
 + v.db.connect map=sender_point@FIDIMO_Cele -gl layer=1 fs=|
 + cut -f2 -d|
 + table=sender_point
 + [ -z sender_point ]
 + cut -f3 -d|
 + v.db.connect -gl fs=| map=sender_point@FIDIMO_Cele layer=1
 + keycol=cat
 + cut -f4 -d|
 + v.db.connect -gl fs=| map=sender_point@FIDIMO_Cele layer=1
 + database=/home/radinger/Documents/GRASS_locations/Cele_loc
 ation/FIDIMO_Cele/sqlite.db
 + v.db.connect -gl fs=| map=sender_point@FIDIMO_Cele layer=1
 + cut -f5 -d|
 + driver=sqlite
 + col=testcol
 + [ testcol = cat ]
 + cut -d| -f1,2
 + v.info --q -c map=sender_point@FIDIMO_Cele layer=1
 + grep |testcol$
 + [ 0 -ne 0 ]
 + [ sqlite = sqlite ]