Re: [GRASS-user] v.water.outlet
On Thu, Jan 5, 2012 at 12:16 PM, Paolo Cavallini cavall...@faunalia.it 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
Re: [GRASS-user] v.water.outlet
On Thu, Jan 5, 2012 at 12:12 PM, Massimiliano Cannata massimiliano.cann...@supsi.ch 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
On Fri, Jan 6, 2012 at 9:42 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 06/01/12 09:23, Markus Metz wrote: On Thu, Jan 5, 2012 at 12:12 PM, Massimiliano Cannata massimiliano.cann...@supsi.ch 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] Connecting table
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 mi...@arava.co.il 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 mi...@arava.co.il 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 new_vector 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 at 9:13 PM, Micha Silver mi...@arava.co.il wrote:
On 01/03/2012 04:50 PM, Bulent Arikan wrote:
Dear List,
I rasterized a centroid and ran 'r.univar', whose extended
[GRASS-user] problems with colors resulting of an image fusion
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
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 centroids lay=2 col="cat_2 integer, other
columns..."
v.to.db centroids lay=2 column=cat_2 option=cat
Thank you,
Bulent
On Thu, Jan 5, 2012 at 12:27 PM, Micha
Silver mi...@arava.co.il
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
