[GRASS-user] ET maps with MODIS

GRASS GRASS user
1

Dear GRASS users,

we calculated some ET maps based on MODIS data using the evapo.potrad and evapo.senay module. It worked fine. But I am not sure, wheather we have to correct the MODIS land surface temperature based on the time of recording.

Best regards

Niels

--

-----------------------------------------------------
Dr. Niels Thevs
Institute of Botany and Landscape Ecology
Greifswald University
Grimmer Strasse 88
17487 Greifswald
Germany

Tel.: +49-3834-86-4131
Fax: +49-3834-86-4114

-----------------------------------------------------

2

Moin grass-user,

I'd like to get the result of r.coin into a table-format to import it in
a database. Before I start fighting with sed and awk:
Do someone know a faster way?

Thanks in advance,
Achim

PS:
Also r.report or r.stat would work, but r.coin most looks like a table

it looks like:
(..header...)
| cat# | 1 | 2 | 3 | 4 | 6 |
       9 | w cat 0 | w/o cat 0 |
|--------------------------------------------------------------------------------------------------------|
|a -1610000 | 3.26 | 0.00 | 0.00 | 735.20 | 0.00
| 0.00 | 738.46 | 738.46 |
|f -1250000 | 6.50 | 0.00 | 0.00 | 0.00 | 0.00
| 0.00 | 6.50 | 6.50 |
|_ -1090000 | 0.82 | 0.00 | 0.00 | 0.00 | 0.00
| 0.00 | 0.82 | 0.82 |
|b -1070000 | 0.00 | 0.00 | 19.12 | 0.00 | 0.00
| 0.00 | 19.12 | 19.12 |
|a -1050000 | 0.00 | 0.00 | 6.36 | 0.00 | 0.00
| 0.00 | 6.36 | 6.36 |
(...)

3

Hi all,

I wrote an awk-sed-script (for my specific situation) to do it...

Afterwards I recognized, that it is now general enough. So I used a
combination of r.mapcalc "preprocessing" and r.stats and combined the
result within the database.

All the best,
Achim

Achim Kisseler schrieb:

Moin grass-user,

I'd like to get the result of r.coin into a table-format to import it in
a database. Before I start fighting with sed and awk:
Do someone know a faster way?

Thanks in advance,
Achim

PS:
Also r.report or r.stat would work, but r.coin most looks like a table

it looks like:
(..header...)
| cat# | 1 | 2 | 3 | 4 | 6 |
       9 | w cat 0 | w/o cat 0 |
|--------------------------------------------------------------------------------------------------------|
|a -1610000 | 3.26 | 0.00 | 0.00 | 735.20 | 0.00
| 0.00 | 738.46 | 738.46 |
|f -1250000 | 6.50 | 0.00 | 0.00 | 0.00 | 0.00
| 0.00 | 6.50 | 6.50 |
|_ -1090000 | 0.82 | 0.00 | 0.00 | 0.00 | 0.00
| 0.00 | 0.82 | 0.82 |
|b -1070000 | 0.00 | 0.00 | 19.12 | 0.00 | 0.00
| 0.00 | 19.12 | 19.12 |
|a -1050000 | 0.00 | 0.00 | 6.36 | 0.00 | 0.00
| 0.00 | 6.36 | 6.36 |
(...)

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

4

Hi,

I am using

v.to.db map=af_grid option=area columns=area type=centroid units=kilometers

(in GRASS65 opensuse 11.1 64)

to calculate the area size. Some of the areas are very wrong. Its a grid
in lat-lon, where areas should be nearly equal in size.

Is this a known bug? I don't guess so.
Do I something wrong?

Thanks,
Achim

PS:
already did v.clean, r.mask -r (<- should not be have an effect)

5

Achim Kisseler wrote:

Hi,

I am using

v.to.db map=af_grid option=area columns=area type=centroid units=kilometers
  

try units=hectares, kilometers are not an areal unit, don't know why v.to.db executes at all

you can cross-check the results by querying the map

hope that helps,

Markus M

(in GRASS65 opensuse 11.1 64)

to calculate the area size. Some of the areas are very wrong. Its a grid
in lat-lon, where areas should be nearly equal in size.

Is this a known bug? I don't guess so.
Do I something wrong?

Thanks,
Achim

PS:
already did v.clean, r.mask -r (<- should not be have an effect)
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

6

Hi Markus,

its the same with hectares; kilometers writes out the result in
square-kilometers.

Achim

Markus Metz schrieb:

Achim Kisseler wrote:

Hi,

I am using

v.to.db map=af_grid option=area columns=area type=centroid
units=kilometers
  

try units=hectares, kilometers are not an areal unit, don't know why
v.to.db executes at all

you can cross-check the results by querying the map

hope that helps,

Markus M

(in GRASS65 opensuse 11.1 64)

to calculate the area size. Some of the areas are very wrong. Its a grid
in lat-lon, where areas should be nearly equal in size.

Is this a known bug? I don't guess so.
Do I something wrong?

Thanks,
Achim

PS:
already did v.clean, r.mask -r (<- should not be have an effect)
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

Achim, how was the grid generated? Could you put some fo the results here?

Pablo.

Date: Mon, 7 Dec 2009 18:32:14 +0100
From: ak7@jupiter.uni-freiburg.de
To: markus.metz.giswork@googlemail.com
Subject: Re: [GRASS-user] bug?: v.to.db wrong area
CC: grass-user@lists.osgeo.org

Hi Markus,

its the same with hectares; kilometers writes out the result in
square-kilometers.

Achim

Markus Metz schrieb:

Achim Kisseler wrote:

Hi,

I am using

v.to.db map=af_grid option=area columns=area type=centroid
units=kilometers

try units=hectares, kilometers are not an areal unit, don’t know why
v.to.db executes at all

you can cross-check the results by querying the map

hope that helps,

Markus M

(in GRASS65 opensuse 11.1 64)

to calculate the area size. Some of the areas are very wrong. Its a grid
in lat-lon, where areas should be nearly equal in size.

Is this a known bug? I don’t guess so.
Do I something wrong?

Thanks,
Achim

PS:
already did v.clean, r.mask -r (<- should not be have an effect)

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

Agora a pressa é amiga da perfeição. Chegou Windows 7. Conheça.

8

I made the grid with:

-%<--
v.mkgrid --overwrite map=$1_grid_all grid="$north_south,$east_west"
position=coor coor="$southwest_corner" box="0:30,0:30"

echo "
########################################
## shrink grid to land-surface"
sqlite3 $2 "drop table $1_grid_patched"
v.overlay --o ainput=$1_grid_all binput=$1_area output=$1_grid_patched
v.db.addcol map=$1_grid_patched columns="keep INT"
sqlite3 $2 "UPDATE $1_grid_patched SET keep=1 WHERE (NOT b_cat IS NULL
OR ((a_row*1000)+a_col) IN (SELECT (a_row*1000)+a_col FROM
$1_grid_patched WHERE NOT b_cat IS NULL))"
v.extract input=$1_grid_patched output=$1_grid_extracted where="keep=1"
--overwrite
v.db.addcol map=$1_grid_extracted columns="dissolve INT"
sqlite3 $2 "UPDATE $1_grid_extracted SET dissolve=((a_row*1000)+a_col)"
v.dissolve --overwrite input=$1_grid_extracted output=$1_grid
column=dissolve layer=1

(...)

sh renew_cats.sh $1_grid 2 centroid
db.droptable -f table=$1_grid
v.db.connect -d map=$1_grid
v.db.addtable map=$1_grid
-%<--

In the picture:
yellow grids seem ok (301.444-279.003 km²)
one is 194.532
the rest is 2.545.231-11.559.210

Achim

Pablo Carreira schrieb:

Achim, how was the grid generated? Could you put some fo the results here?

Pablo.

Date: Mon, 7 Dec 2009 18:32:14 +0100
From: ak7@jupiter.uni-freiburg.de
To: markus.metz.giswork@googlemail.com
Subject: Re: [GRASS-user] bug?: v.to.db wrong area
CC: grass-user@lists.osgeo.org

Hi Markus,

its the same with hectares; kilometers writes out the result in
square-kilometers.

Achim

Markus Metz schrieb:
>
> Achim Kisseler wrote:
>> Hi,
>>
>> I am using
>>
>> v.to.db map=af_grid option=area columns=area type=centroid
>> units=kilometers
>>
> try units=hectares, kilometers are not an areal unit, don't know why
> v.to.db executes at all
>
> you can cross-check the results by querying the map
>
> hope that helps,
>
> Markus M
>
>> (in GRASS65 opensuse 11.1 64)
>>
>> to calculate the area size. Some of the areas are very wrong. Its a

grid

>> in lat-lon, where areas should be nearly equal in size.
>>
>> Is this a known bug? I don't guess so.
>> Do I something wrong?
>>
>> Thanks,
>> Achim
>>
>> PS:
>> already did v.clean, r.mask -r (<- should not be have an effect)
>> _______________________________________________
>> 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

------------------------------------------------------------------------
Agora a pressa é amiga da perfeição. Chegou Windows 7. Conheça.
<http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539&gt;

(attachments)

grids.png

9

I think "v.dissolve" corrupted it.

I solved it by making a raster map and then a vector map again.

Thanks, Markus and Pablo,

Achim

Achim Kisseler schrieb:

I made the grid with:

-%<--
v.mkgrid --overwrite map=$1_grid_all grid="$north_south,$east_west"
position=coor coor="$southwest_corner" box="0:30,0:30"

echo "
########################################
## shrink grid to land-surface"
sqlite3 $2 "drop table $1_grid_patched"
v.overlay --o ainput=$1_grid_all binput=$1_area output=$1_grid_patched
v.db.addcol map=$1_grid_patched columns="keep INT"
sqlite3 $2 "UPDATE $1_grid_patched SET keep=1 WHERE (NOT b_cat IS NULL
OR ((a_row*1000)+a_col) IN (SELECT (a_row*1000)+a_col FROM
$1_grid_patched WHERE NOT b_cat IS NULL))"
v.extract input=$1_grid_patched output=$1_grid_extracted where="keep=1"
--overwrite
v.db.addcol map=$1_grid_extracted columns="dissolve INT"
sqlite3 $2 "UPDATE $1_grid_extracted SET dissolve=((a_row*1000)+a_col)"
v.dissolve --overwrite input=$1_grid_extracted output=$1_grid
column=dissolve layer=1

(...)

sh renew_cats.sh $1_grid 2 centroid
db.droptable -f table=$1_grid
v.db.connect -d map=$1_grid
v.db.addtable map=$1_grid
-%<--

In the picture:
yellow grids seem ok (301.444-279.003 km²)
one is 194.532
the rest is 2.545.231-11.559.210

Achim

Pablo Carreira schrieb:

Achim, how was the grid generated? Could you put some fo the results here?

Pablo.

Date: Mon, 7 Dec 2009 18:32:14 +0100
From: ak7@jupiter.uni-freiburg.de
To: markus.metz.giswork@googlemail.com
Subject: Re: [GRASS-user] bug?: v.to.db wrong area
CC: grass-user@lists.osgeo.org

Hi Markus,

its the same with hectares; kilometers writes out the result in
square-kilometers.

Achim

Markus Metz schrieb:

Achim Kisseler wrote:

Hi,

I am using

v.to.db map=af_grid option=area columns=area type=centroid
units=kilometers

try units=hectares, kilometers are not an areal unit, don't know why
v.to.db executes at all

you can cross-check the results by querying the map

hope that helps,

Markus M

(in GRASS65 opensuse 11.1 64)

to calculate the area size. Some of the areas are very wrong. Its a

grid

in lat-lon, where areas should be nearly equal in size.

Is this a known bug? I don't guess so.
Do I something wrong?

Thanks,
Achim

PS:
already did v.clean, r.mask -r (<- should not be have an effect)
_______________________________________________
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

------------------------------------------------------------------------
Agora a pressa é amiga da perfeição. Chegou Windows 7. Conheça.
<http://www.microsoft.com/brasil/windows7/default.html?WT.mc_id=1539&gt;

------------------------------------------------------------------------

------------------------------------------------------------------------

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