Re: [GRASS-user] Connecting table

[Micha Silver]

  
  
On 01/06/2012 02:31 PM, Bulent Arikan wrote:
OK! That makes sense now. I have one last standing
  issue about this. It seems that the second layer I created using
  'v.db.addtable' (after setting the dbf to SQL and importing a
  centroid –vector– map) has a column for CAT but it does not have a
  number. I checked the book to make sure and it says it should have
  a number and it does not have to be continuous from the first
  layer. 
  

  
  I tried assigning a CAT# using 'v.category' and
'v.db.connect' but I still do not see a number in CAT column. I
think I should have a number there so that my "...WHERE cat =
" argument makes sense. Any ideas how to correct this?
  
  


Probably v.to.db will do it. Say you want a column cat_2 in layer2
then something like:
v.db.addcolumn  lay=2 col="cat_2 integer, "
v.to.db  lay=2 column=cat_2 option=cat
 

  Thank you,
  
  
  Bulent   

On Thu, Jan 5, 2012 at 12:27 PM, Micha
  Silver 
  wrote:
  

   On 01/05/2012 10:49 AM, Bulent Arikan
wrote:
Hi,
  
  
  I really would like to learn more about the SQL
command-based operations in GRASS. To summarize: I
have created a new mapset where the driver is set to
SQL. I have created second layers for all of my
centroids (the tables in the second layers have a
different name like "Db_runivar" ). I used
'v.db.addtable' to have GRASS create columns to
upload the results from extended statistics of
r.univar text files (e.g., Db_runivar.txt) for each
centroid. 
  
  
  Now, I have been trying to get 'db.execute' to
work. One suggestion was that I use a loop for
automated updating (I am assuming
  that I have to type this in the Terminal):
  
  
  > while read l; do \
      col=`echo $l | cut -d= -f1`; val=`echo $l |
  cut -d= -f2`; \
      sqlite3 sqlite.db "UPDATE centroid SET
  ${col}=${val} ;"; \
  > done < univar.txt
  

  

  I came up with a statement
  (below) by looking at the manual in 'r.univar' to
  create an SQL command file:
  

  
   
  sed -e '1d' Dogubayazit_runivar.txt |
awk -F'l' '{print "UPDATE Dogubayazit_runivar
SET non_null_cells = "$2", null_cells = "$3",
min = "$4", max = "$5", range = "$6", mean =
"$7", mean_of_abs = "$8", stddev = "$9",
variance = "$10", coeff_var = "$11", sum =
"$12", sum_abs = "$13", first_quart = "$14",
median = "$15", third_quart = "$16", perc_90  =
"$17" WHERE cat = "$1";"}'  

  



  
  The above will create a list of update statements, one for
  each row in the runivar.txt file. You can't feed
  db.execute a list of statements, only one at a time. So
  you'll have to dump the output of the above command into
  an intermediary file, then use the db.execute "input"
  parameter to specify that file of SQL commands. 
  
  It might be worth noting that if you have many UPDATE's,
  then doing them one by one with an individual call to the
  database each time might take a bit of time. In this case,
  going back to sqlite, you could wrap all the UPDATE
  statements between a BEGIN...COMMIT clause, then feed that
  file to db.execute (or directly to sqlite), and it will
  open one connection, and push all the updates at once. For
  many 1000's of rows this would probably be much faster.
  

  
  
that can be used in
'db.execute' but I am getting a syntax error:

  
DBMI-SQLite driver error:
Error in sqlite3_prepare():
near "sed": syntax error
ERROR: Error whi

[GRASS-user] problems with colors resulting of an image fusion

[Moritz Lennert]

Hi everyone,

I have some troubles with image fusion through IHS transformation of a 
Landsat image. Using d.rgb to display the resulting r,g,b channels gives 
completely different colors than the original d.rgb on the 30,20,10 
Landsat channels.


On this image:

http://geog-pc40.ulb.ac.be/grass/landsat_fusion.png

You see the original d.rgb on the upper left, the panchromatic channel 
on the lower left and the result of the IHS transformation on the lower 
right.


All channels have a grey.eq color table.

The image

http://geog-pc40.ulb.ac.be/grass/landsat_fusion2.png

shows the same, but zoomed-in, showing that the fusion seems to have 
worked (i.e. the resulting image has higher resolution).


Does anybody have an idea of might be the problem ?

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

Re: [GRASS-user] Connecting table

[Bulent Arikan]

OK! That makes sense now. I have one last standing issue about this. It
seems that the second layer I created using 'v.db.addtable' (after setting
the dbf to SQL and importing a centroid –vector– map) has a column for CAT
but it does not have a number. I checked the book to make sure and it says
it should have a number and it does not have to be continuous from the
first layer.

I tried assigning a CAT# using 'v.category' and 'v.db.connect' but I still
do not see a number in CAT column. I think I should have a number there so
that my "...WHERE cat = " argument makes sense. Any ideas how to
correct this?

Thank you,

Bulent

On Thu, Jan 5, 2012 at 12:27 PM, Micha Silver  wrote:

> **
> On 01/05/2012 10:49 AM, Bulent Arikan wrote:
>
> Hi,
>
>  I really would like to learn more about the SQL command-based operations
> in GRASS. To summarize: I have created a new mapset where the driver is set
> to SQL. I have created second layers for all of my centroids (the tables in
> the second layers have a different name like "Db_runivar" ). I used
> 'v.db.addtable' to have GRASS create columns to upload the results from
> extended statistics of r.univar text files (e.g., Db_runivar.txt) for each
> centroid.
>
>  Now, I have been trying to get 'db.execute' to work. One suggestion was
> that I use a loop for automated updating (I am assuming that I have to
> type this in the Terminal):
>
>  > while read l; do \
> col=`echo $l | cut -d= -f1`; val=`echo $l | cut -d= -f2`; \
> sqlite3 sqlite.db "UPDATE centroid SET ${col}=${val} ;"; \
> > done < univar.txt
>
>
>  I came up with a statement (below) by looking at the manual in
> 'r.univar' to create an SQL command file:
>
>   sed -e '1d' Dogubayazit_runivar.txt | awk -F'l' '{print "UPDATE
> Dogubayazit_runivar SET non_null_cells = "$2", null_cells = "$3", min =
> "$4", max = "$5", range = "$6", mean = "$7", mean_of_abs = "$8", stddev =
> "$9", variance = "$10", coeff_var = "$11", sum = "$12", sum_abs = "$13",
> first_quart = "$14", median = "$15", third_quart = "$16", perc_90  = "$17"
> WHERE cat = "$1";"}'
>
>
> The above will create a list of update statements, one for each row in the
> runivar.txt file. You can't feed db.execute a list of statements, only one
> at a time. So you'll have to dump the output of the above command into an
> intermediary file, then use the db.execute "input" parameter to specify
> that file of SQL commands.
>
> It might be worth noting that if you have many UPDATE's, then doing them
> one by one with an individual call to the database each time might take a
> bit of time. In this case, going back to sqlite, you could wrap all the
> UPDATE statements between a BEGIN...COMMIT clause, then feed that file to
> db.execute (or directly to sqlite), and it will open one connection, and
> push all the updates at once. For many 1000's of rows this would probably
> be much faster.
>
>
>  that can be used in 'db.execute' but I am getting a syntax error:
>
>  DBMI-SQLite driver error:
> Error in sqlite3_prepare():
> near "sed": syntax error
> ERROR: Error while executing: 'sed -e '1d' 
>
>
> What seems to be the problem?
> Thank you for your time.
>
>  Bulent
>
> On Wed, Jan 4, 2012 at 9:16 AM, Micha Silver  wrote:
>
>>  On 01/03/2012 10:44 PM, Bulent Arikan wrote:
>>
>> Thank you! This seems to be an interesting solution to the problem
>> especially because it involves changing the driver from DBF to SQLITE. I
>> ended up using 'v.rast.stats', which adds columns for extended statistics
>> and uploads values all at once. The only thing is: data are recorded as
>> part of the same layer (i.e., Layer 1). So, I cheated!
>>
>>
>>
>>  Yes, v.rast.stats is definitely the way to go if you want raster
>> univariate statistics pushed into a polygon vector.
>>
>>
>>
>>  However, I started trying your method. I created a new mapset to use
>> sqlite and copied some vector maps from a mapset where default driver is
>> DBF. I defined SQLITE as the new driver in the new mapset using
>> 'db.connect'
>> (driver=sqlite, database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db', no
>> flags checked). Then I wanted to use 'v.db.connect' for a vector map but I
>> cannot select table name etc. I also tried just using 'v.db.connect' but I
>> still cannot see anything under Table. So. I am confused about how to
>> define a new driver in a mapset.
>>
>>
>>  I do as follows:
>> eval `g.gisenv`
>> (This creates the environment variables for GISDBASE, etc.)
>> Now:
>> db.connect driv=sqlite database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db
>>
>> Next:
>> g.copy vect=old,new
>> to create a new copy of the original vector. The original will still have
>> its attrib table as dbf. THe new copy will have an sqlite based attribute
>> table.
>> Now you can do:
>>
>> v.db.addcol  col="..., ..." .
>>
>> BTW, I think that v.rast.stats will automatically create the needed
>> columns .
>>
>> Cheers,
>> Micha
>>
>>
>>  Thank you again,
>>
>>  Bulent
>>
>> On Tue, Jan 3, 2012 a

Re: [GRASS-user] v.water.outlet

[Markus Metz]

On Fri, Jan 6, 2012 at 9:42 AM, Moritz Lennert
 wrote:
> On 06/01/12 09:23, Markus Metz wrote:
>>
>> On Thu, Jan 5, 2012 at 12:12 PM, Massimiliano Cannata
>>   wrote:
>>>
>>> Moreover,
>>> check that your dem has sinks filled (r.fill.dir)
>>
>>
>> Since the drainage map has been created by r.watershed, sink filling
>> is not only not needed but does more harm than good and should not be
>> used to prepare a DEM for r.watershed.
>
>
> for r.water.outlet I suppose...
>
> Could you explain why ?

Because r.water.outlet generates a watershed basin from a drainage
direction map from r.watershed (says the manual), more generally,
r.water.outlet uses as input map only a drainage map and not a DEM,
thus it does not matter where the drainage map comes from, it could in
theory also be properly encoded moving directions from a cost surface
analysis. As pointed out by Micha and you, care must be taken with the
coordinates, otherwise an unexpectedly small basin will be delineated.
Additionally, r.water.outlet will most probably not work properly if
the current region does not match exactly the drainage map.

r.watershed has been designed from the very beginning by Chuck
Ehlschlaeger in 1989 to work with raw DEMs and to produce realistic
output without sink filling (see references in the manual).

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

Re: [GRASS-user] v.water.outlet

[Moritz Lennert]

On 06/01/12 09:23, Markus Metz wrote:

On Thu, Jan 5, 2012 at 12:12 PM, Massimiliano Cannata
  wrote:

Moreover,
check that your dem has sinks filled (r.fill.dir)


Since the drainage map has been created by r.watershed, sink filling
is not only not needed but does more harm than good and should not be
used to prepare a DEM for r.watershed.


for r.water.outlet I suppose...

Could you explain why ?

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

Re: [GRASS-user] v.water.outlet

[Markus Metz]

On Thu, Jan 5, 2012 at 12:12 PM, Massimiliano Cannata
 wrote:
> Moreover,
> check that your dem has sinks filled (r.fill.dir)

Since the drainage map has been created by r.watershed, sink filling
is not only not needed but does more harm than good and should not be
used to prepare a DEM for r.watershed.

Markus M

>
>
>
> On 01/04/2012 08:55 PM, Micha Silver wrote:
>
> On 01/04/2012 07:27 PM, Paolo Cavallini wrote:
>
> Hi all.
> I tried this command, but I always get a map full of 0. I start from a
> drainage map from r.watershed, as described. Anyone confirms, or am I doing
> something wrong?
> All the best.
>
> I guess you mean r.water.outlet?
>
> You probably know already, but maybe it's worth repeating:
>
> 1- The input must be the drainage *direction* map from r.watershed.
>
> 2- And it's crucial that the easting and northing parameters for the outlet
> point lay exactly on a stream. Zoom in very close to the streams raster at
> the outlet point and check for the exact coordinates.
>
>
> --
> Micha Silver
> GIS Consultant, Arava Development Co.
> http://www.surfaces.co.il
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> --
>
> Dr. Eng. Massimiliano Cannata
> Responsabile Area Geomatica
> Istituto Scienze della Terra
> Scuola Universitaria Professionale della Svizzera Italiana
> Via Trevano, c.p. 72
> CH-6952 Canobbio-Lugano
> Tel: +41 (0)58 666 62 14
> Fax +41 (0)58 666 62 09
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.water.outlet

[Markus Metz]

On Thu, Jan 5, 2012 at 12:16 PM, Paolo Cavallini  wrote:
> Il 04/01/2012 20:55, Micha Silver ha scritto:
>
>
>> I guess you mean r.water.outlet?
>
>
> Yes, sorry.
>
>
>> 1- The input must be the drainage *direction* map from r.watershed.
>
>
> ok
>
>
>> 2- And it's crucial that the easting and northing parameters for the
>> outlet point lay
>> exactly on a stream. Zoom in very close to the streams raster at the
>> outlet point and
>> check for the exact coordinates.
>
>
> Checked, it seems ok.
> The output maps is all 0s, with only one cell (close to the point I chose,
> but not on it) with value 1.

This is weird. The cell in which the point you chose is located should
always be included in the basin created by r.water.outlet. Make sure
your computational region is set to the drainage raster. At least we
know now that r.water.outlet produces something, because the output is
not all 0s, at least one cell is 1.

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