Re: [GRASS-user] global radiation calculated with r.sun seems to be very high

[Frank Reekers]

the projection and region settings:

GRASS 6.4.0RC6 (GRASS)> g.region -p
projection: 99 (Transverse Mercator)
zone:   0
datum:  potsdam
ellipsoid:  bessel
north:  5795499.5
south:  5793999.5
west:   3434499.5
east:   3435999.5
nsres:  1
ewres:  1
rows:   1500
cols:   1500
cells:  225

GRASS 6.4.0RC6 (GRASS)> g.proj -p
-PROJ_INFO-
name   : Transverse Mercator
proj   : tmerc
datum  : potsdam
ellps  : bessel
lat_0  : 0
lon_0  : 9
k  : 1
x_0: 350
y_0: 0
no_defs: defined
-PROJ_UNITS
unit   : Meter
units  : Meters
meters : 1

Hamish schrieb


what does 'g.region -p' say?
how about 'g.proj -p'?


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

Re: [GRASS-user] elevation profile

[Hamish]

yet another two methods to try-

(spearfish dataset)

# v.out.ascii | r.profile method

g.region -d
v.in.region sp_box
v.type in=t_powerlines out=t_powerline type=boundary,line
v.overlay ain=t_powerline bin=sp_box out=sp_powerline atype=line op=and
v.build.polylines in=sp_powerline  out=sp_powerline_pl
g.remove v=sp_box,t_powerline,sp_powerline

v.out.ascii in=sp_powerline_pl format=standard | grep  '^ ' | \
  r.profile -g in=elevation.dem res=30



# v.to.rast MASK method

v.type in=t_powerlines out=t_powerline type=boundary,line
v.category in=t_powerline out=t_powerline_with_cat option=add
v.to.rast in=t_powerline_with_cat out=MASK use=val value=1
g.remove v=t_powerline,t_powerline_with_cat

r.out.xyz elevation.dem
g.remove MASK



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

Re: [GRASS-user] global radiation calculated with r.sun seems to be very high

[Hamish]

Hi,

does anyone have the "definitive" way of converting micro-Einsteins (aka
micro-moles of photons) in the PAR part of the spectrum to watts? I assume
you'd have to use the linke factor to estimate how much energy gets through
into the other parts of the full light spectrum as part of the energy 
integration.

I can figure out a simple method but I wouldn't trust it for definitively
calibrating the model, or at least am always on the lookout for something
better. Ultimately I'd love to be able to use our Li-COR time-series data
to calibrate the r.sun model, producing a local Linke number from sunny day
data and better cloud diffusion coefficients for cloudy ones (deficit from
modeled clear-sky estimate).

at minimum converting a chunk of that uE PAR data it could tell us which
of the two (or both) is right/wrong.


as for the question about hourly integrations, I'm not sure it is possible
without hacking the code. The best you could do is calc instantaneous flux
at the bottom of each hour and (non-correctly) pretend that value is the
average over the whole hour. or just present the instantaneous value at
the top of each value, document it, and leave it at that.


Hamish


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

Re: [GRASS-user] compiling grass 7 external modules

[Jarek Jasiewicz]

GRASS 7 doesn't have "install" targets. These were only added to 6.x
quite recently, and haven't been sync'd to 7.0 (the build system has
changed a lot between 6.x and 7.0).

You can use e.g.:

make ... ARCH_DISTDIR=...

to cause the output file(s) to be created somewhere other than the
dist. directory; ARCH_DISTDIR should refer to the base directory
of the GRASS installation, i.e. $GISBASE.

  

Glynn!
Thanks for explanation.
Jarek
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compiling grass 7 external modules

[Glynn Clements]

Jarek Jasiewicz wrote:

> In GRASS65 I create dir in raster or vector directory, program module 
> in  I want to create, next make, sudo make install, ready
> 
> in grass 7 not.
> after make install: "no rules to make install. Stop". Of course make 
> goes well, without warnings and errors, objects are created in OBJ.xxx 
> directory etc.
> 
> The same repeats when I do "make install" in any module directory which 
> I change it for my purposes.

GRASS 7 doesn't have "install" targets. These were only added to 6.x
quite recently, and haven't been sync'd to 7.0 (the build system has
changed a lot between 6.x and 7.0).

You can use e.g.:

make ... ARCH_DISTDIR=...

to cause the output file(s) to be created somewhere other than the
dist. directory; ARCH_DISTDIR should refer to the base directory
of the GRASS installation, i.e. $GISBASE.

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

[GRASS-user] compiling grass 7 external modules

[Jarek Jasiewicz]

Hi
How to do that?

In GRASS65 I create dir in raster or vector directory, program module 
in  I want to create, next make, sudo make install, ready


in grass 7 not.
after make install: "no rules to make install. Stop". Of course make 
goes well, without warnings and errors, objects are created in OBJ.xxx 
directory etc.


The same repeats when I do "make install" in any module directory which 
I change it for my purposes.


Thanks in advance for explanation
Jarek
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: running KyngChaos GRASS on Mac from command line

[stephen sefick]

Another route which is more of a pain in the hanches is to grab all of
the dependencies from fink and then roll your own.

On Thu, Jul 15, 2010 at 3:25 PM, Neil Best  wrote:
>
>
> William Kyngesburye wrote:
>>
>> The equivalent to the *nix startup 'grass64' in the Mac app package is
>> '/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh'.
>>
>
> Ah, yes, thank you.  I looked right at it when browsing the app contents but
> it didn't register.
> --
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/running-KyngChaos-GRASS-on-Mac-from-command-line-tp5299030p5299172.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>



-- 
Stephen Sefick

| Auburn University                                   |
| Department of Biological Sciences           |
| 331 Funchess Hall                                  |
| Auburn, Alabama                                   |
| 36849                                                    |
|___|
| sas0...@auburn.edu                             |
| http://www.auburn.edu/~sas0025             |
|___|

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods.  We are mammals, and have not exhausted the
annoying little problems of being mammals.

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

[GRASS-user] Re: running KyngChaos GRASS on Mac from command line

[Neil Best]

William Kyngesburye wrote:
> 
> The equivalent to the *nix startup 'grass64' in the Mac app package is
> '/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh'.
> 

Ah, yes, thank you.  I looked right at it when browsing the app contents but
it didn't register.
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/running-KyngChaos-GRASS-on-Mac-from-command-line-tp5299030p5299172.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] elevation profile

[Dylan Beaudette]

This might be useful:

http://casoilresource.lawr.ucdavis.edu/drupal/node/375

Cheers,
Dylan

On Thursday 15 July 2010, John Callahan wrote:
> Hopefully a quick question that I'm struggling with.  (I'm a long-time GIS
> user but trying to move my work to GRASS and other FOSS4G.)   I'm using
> GRASS 6.4 RC6 on Windows XP.
>
> I have a raster grid representing elevation at 2meter resolution. I have a
> line shapefile representing roads (about 20 roads total).  I would like to
> get ASCII text files of x,y,z at about 1 or 2 meter intervals along each
> road.  Any ides of what I can try?
>
> I thought v.drape might work. This converts my 2D road shapefile to 3D, but
> I'm not sure where to go from there.  And this doesn't help getting 1 or 2
> meter intervals.  I also tried r.profile but this requires input as a
> listing of x,y coordinates, not shapefiles.  I know there's a step here I'm
> missing.
>
> - John
>
> **
> John Callahan, Geographic Information Scientist
> Delaware Geological Survey, University of Delaware
> URL: http://www.dgs.udel.edu
> **



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] running KyngChaos GRASS on Mac from command line

[William Kyngesburye]

The equivalent to the *nix startup 'grass64' in the Mac app package is 
'/Applications/GRASS-6.4.app/Contents/MacOS/grass.sh'.

On Jul 15, 2010, at 2:49 PM, Neil Best wrote:

> 
> Mr. Kyngesburye and fellow OSX GRASS users, is it possible to run
> GRASS-6.4.app in a way that doesn't pop over to a new Terminal?  As opposed
> to saying 'open -a "GRASS-6.4.app"' per GRASS-6.4-ReadMe.rtf, that is.  Call
> me an endangered species, but I like to run stuff from the emacs shell --
> Aquamacs these days.  Going on 20 years of muscle memory -- yikes!  :)
> 
> Neil
> 
> 
> -- 
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/running-KyngChaos-GRASS-on-Mac-from-command-line-tp5299030p5299030.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly what the 
universe is for and why it is here, it will instantly disappear and be replaced 
by something even more bizarrely inexplicable.  There is another theory which 
states that this has already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro


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

Re: [GRASS-user] elevation profile

[Ricardo Filipe Soares Garcia da]

Hi

I think r.profile[1] can probably help you get to the output you want.
In the past I had looked into doing the exact same thing as you. I
ended up using SAGA GIS[2], as it has a predefined module that does
exactly this task, and I was in a hurry ;)

Good luck


[1] - http://grass.itc.it/grass64/manuals/html64_user/r.profile.html
[2] - http://www.saga-gis.org

On Thu, Jul 15, 2010 at 8:41 PM, John C. Tull  wrote:
> Hi John,
> You will likely get a more complete answer from others, but you seem to be
> on the right track with v.drape. From there, you can add a column for
> cumulative length with v.db.addcol, then run v.to.db with option=length to
> add a length column to your 3d vector. You might be able to subsample from
> there.
> Another possibility would be to run v.segment to generate points at your
> desired length interval for the original vector. Then you could run v.drape
> on the resulting points file and work from there or somehow pipe the point
> coordinates into r.profile.
> Good luck,
> John
> On Jul 15, 2010, at 12:25 PM, John Callahan wrote:
>
> Hopefully a quick question that I'm struggling with.  (I'm a long-time GIS
> user but trying to move my work to GRASS and other FOSS4G.)   I'm using
> GRASS 6.4 RC6 on Windows XP.
>
> I have a raster grid representing elevation at 2meter resolution. I have a
> line shapefile representing roads (about 20 roads total).  I would like to
> get ASCII text files of x,y,z at about 1 or 2 meter intervals along each
> road.  Any ides of what I can try?
>
> I thought v.drape might work. This converts my 2D road shapefile to 3D, but
> I'm not sure where to go from there.  And this doesn't help getting 1 or 2
> meter intervals.  I also tried r.profile but this requires input as a
> listing of x,y coordinates, not shapefiles.  I know there's a step here I'm
> missing.
>
> - John
>
> **
> John Callahan, Geographic Information Scientist
> Delaware Geological Survey, University of Delaware
> URL: http://www.dgs.udel.edu
> **
> ___
> 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
>
>



-- 
___ ___ __
Ricardo Garcia Silva
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] running KyngChaos GRASS on Mac from command line

[Neil Best]

Mr. Kyngesburye and fellow OSX GRASS users, is it possible to run
GRASS-6.4.app in a way that doesn't pop over to a new Terminal?  As opposed
to saying 'open -a "GRASS-6.4.app"' per GRASS-6.4-ReadMe.rtf, that is.  Call
me an endangered species, but I like to run stuff from the emacs shell --
Aquamacs these days.  Going on 20 years of muscle memory -- yikes!  :)

Neil


-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/running-KyngChaos-GRASS-on-Mac-from-command-line-tp5299030p5299030.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] elevation profile

[John C. Tull]

Hi John,

You will likely get a more complete answer from others, but you seem to be on 
the right track with v.drape. From there, you can add a column for cumulative 
length with v.db.addcol, then run v.to.db with option=length to add a length 
column to your 3d vector. You might be able to subsample from there.

Another possibility would be to run v.segment to generate points at your 
desired length interval for the original vector. Then you could run v.drape on 
the resulting points file and work from there or somehow pipe the point 
coordinates into r.profile.

Good luck,
John

On Jul 15, 2010, at 12:25 PM, John Callahan wrote:

> Hopefully a quick question that I'm struggling with.  (I'm a long-time GIS 
> user but trying to move my work to GRASS and other FOSS4G.)   I'm using GRASS 
> 6.4 RC6 on Windows XP.
> 
> I have a raster grid representing elevation at 2meter resolution. I have a 
> line shapefile representing roads (about 20 roads total).  I would like to 
> get ASCII text files of x,y,z at about 1 or 2 meter intervals along each 
> road.  Any ides of what I can try?
> 
> I thought v.drape might work. This converts my 2D road shapefile to 3D, but 
> I'm not sure where to go from there.  And this doesn't help getting 1 or 2 
> meter intervals.  I also tried r.profile but this requires input as a listing 
> of x,y coordinates, not shapefiles.  I know there's a step here I'm missing.
> 
> - John
> 
> **
> John Callahan, Geographic Information Scientist
> Delaware Geological Survey, University of Delaware
> URL: http://www.dgs.udel.edu
> **
> ___
> 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] Re: EPSG code for KML (mi...@arava.co.il)

[John C. Tull]

Hi Michael,

If you create a link to the binary inside the OS X gpsbabel application, you 
should be ok. You can do this, assuming you have the latest gpsbabel binary 
install in your Applications folder, with this command from the Terminal:

sudo ln -s /Applications/GPSBabelFE.app/Contents/MacOS/gpsbabel 
/usr/local/bin/gpsbabel

Alternatively, you can add the path to your Bash profile.

Hope that helps,
John

On Jul 12, 2010, at 4:26 PM, Michael Barton wrote:

> FWIW, I've been teaching a workshop on basic GPS + GIS for archaeology in 
> China, using QGIS. 
> 
> For the Mac at least, the QGIS GPS tools don't work--or don't work correctly. 
> I've got the latest and greatest GPSBabel and QGIS 1.4. The QGIS GPS plugin 
> cannot find GPSBabel. It seems this is because it is assuming that it is set 
> up like on Linux instead of like on the Mac.
> 
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> 
> Date: Mon, 12 Jul 2010 16:20:22 +0300
> From: mi...@arava.co.il
> Subject: Re: [GRASS-user] EPSG code for KML
> To: "Bulent Arikan" 
> Cc: grass-user@lists.osgeo.org
> Message-ID:
><39b431e3aa73dab567afde4e1465855e.squir...@webmail.arava.co.il>
> Content-Type: text/plain;charset=windows-1255
> 
>> On Sat, Jul 10, 2010 at 6:33 PM, Hamish  wrote:
>> 
>>> Bulent wrote:
 I occasionally use Google Earth ?GE? (kml files) and I am aware of the
 fact that there is a bit of distortion (i.e., metric offset) between
>>> GE
 and other projections for a variety of reasons. I am wondering if
>>> anyone
 knows whether there is an EPSG code for KML format so that I can
>>> create
 a LOCATION in Grass using this code and avoid/minimize such
>>> distortions
 when I import vector files.
>>> 
>>> It is fundamentally broken, do not use it for serious GIS work. It is
>>> only valid for visual use and saving cpu cycles on large deployments.
>>> (which is both acceptable and very important for folks like google)
>>> 
>>> (epsg initially refused to include it but finally caved to mass user
>>> pressure)
>>> 
>>> but if you do want to use it, it's just the mercator projection with
>>> a spherical ellipsoid using the WGS84's ellipsoid's major Earth radius
>>> as the only sphere radius. quite simple to define.
>>> 
>>> 
>>> Hamish
>>> ---
>>> 
>> 
>> I was wondering about this. I read several online articles about the
>> problems and the doubts that EPSG has. Unfortunately, I was planning to
>> use
>> this for my archaeological work, which requires accuracy such as locating
>> the trenches and the features, like walls. My issue is, when I need to
>> show
>> polygons (e.g., a rectangle representing a trench), I transfer my GPS
>> points
>> (the readings at 4 corners) to GE and create a polygon there, save it as
>> KML. Then, I open this in QGIS, make a shape file there and import it into
>> GRASS. I suspect there is some distortion and this is a far too
>> complicated
>> routine but I do not know a more practical way.
> 
> I'm curious: Did you try the GPS Tools plugin in QGIS?
> You can simply import the waypoints. They will be in Lon/Lat WGS84,
> avoiding any of the problems with GE projections. THen, in QGIS make your
> polygons, and when you save as shapefile, choose any CRS you want for
> re-projection. Thus your original GPS points, and the polygons will always
> be in Lon/Lat geographic CRS. And for mapping/measuring you can choose any
> appropriate CRS.
> 
> 
>> 
>> ' v.in.gpsbabel ' works fine for retrieving points and tracks from my
>> device. Alternatively, I may digitize the points to create polygons after
>> they are imported in GRASS. I still have to try ' v.in.ascii '
>> 
>> 
>> --
>> B�ENT
>> 
>> This mail was received via Mail-SeCure System.
>> 
>> 
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>> 
>> This mail was received via Mail-SeCure System.
>> 
>> 
>> 
> 
> 
> 
> --
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> End of grass-user Digest, Vol 51, Issue 25
> **
> ___
> 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

[GRASS-user] elevation profile

[John Callahan]

Hopefully a quick question that I'm struggling with.  (I'm a long-time GIS
user but trying to move my work to GRASS and other FOSS4G.)   I'm using
GRASS 6.4 RC6 on Windows XP.

I have a raster grid representing elevation at 2meter resolution. I have a
line shapefile representing roads (about 20 roads total).  I would like to
get ASCII text files of x,y,z at about 1 or 2 meter intervals along each
road.  Any ides of what I can try?

I thought v.drape might work. This converts my 2D road shapefile to 3D, but
I'm not sure where to go from there.  And this doesn't help getting 1 or 2
meter intervals.  I also tried r.profile but this requires input as a
listing of x,y coordinates, not shapefiles.  I know there's a step here I'm
missing.

- John

**
John Callahan, Geographic Information Scientist
Delaware Geological Survey, University of Delaware
URL: http://www.dgs.udel.edu
**
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Issues when reprojecting from a GCS to a PCS

[Neil Best]

Hanlie, judging from a quick scan of your problem you might consider using
gdalbuildvrt to build a virtual mosaic of the inputs and gdalwarp to
reproject the result using the VRT driver.  I have found this to be quite
elegant and efficient since you have accomplished your goal by creating two
tiny XML files, although you may have to edit them by hand if you want to
move the VRT files and adjust the paths to the real data, but it can be
done.  You can even open the VRTs in QGIS if you want to visualize before
importing.  In my experience the GDAL utilities set the resolution of in a
more sensible way that is described clearly in the docs.  If this is a
one-time operation then there is no down side to running it through two
layers of VRT vs. writing the reprojected data out to disk just to have
r.in.gdal write it yet again to your GRASS database.  Let me know if that's
enough to get you going or not.  Have fun!


Neil

-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Issues-when-reprojecting-from-a-GCS-to-a-PCS-tp5297389p5298893.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] global radiation calculated with r.sun seems to be very high

[Nikos Alexandris]

Hi Frank. Could please help me a bit (...two questions below)

Frank Reekers wrote:
> the global radiation, calculated with r.sun, seems to be very high in
> comparison to PVGIS (Photovoltaic Geographical Information System).
>  - r.sun for 14. Feb: ~2363 Wh/m² per day
>  - PVGIS: 1330 Wh/m² per day Irradiation on horizontal plane for
> february on average
> 
> Below the detailed steps I did in GRASS and with PVGIS:
> 1. PVGIS:
> a) http://re.jrc.ec.europa.eu/pvgis/apps3/pvest.php -> search for
> location 'Osnabrueck, Germany' -> choose monthly radiation -> click
> calculate -> the output table shows 1330 Wh/m² Irradiation on horizontal
> plane for february.
> 
> 2. GRASS
> a) Take an existing DEM with the resolution of 1m and set all z-values
> to 68m to have a completely horizontal plane:
> GRASS 6.4.0RC6 (GRASS)> r.mapcalc dsxx94c68=dsxx...@permanent*0+68.00

What is the projection that defines the Location here?

> b) Set Region
> GRASS 6.4.0RC6 (GRASS)> g.region rast=dsxx94c68
> 
> c) Create slope & aspect:
> GRASS 6.4.0RC6 (GRASS)> r.slope.aspect elevation=dsxx94...@permanent
> slope=sdsxx94c68 aspect=adsxx94c68 --overwrite
> 
> d) Run r.sun for day 45:
> GRASS 6.4.0RC6 (GRASS)> r.sun elevin=dsxx94...@permanent
> aspin=adsxx94...@permanent slopein=sdsxx94...@permanent
> glob_rad=g45phxx94c68  day=45 --overwrite
> 
> e) Get global radiation:
> GRASS 6.4.0RC6 (GRASS)> r.what input=g45phxx94c68
> east_north=3435430.596,5794315.99
> 3435430.596|5794315.99||2362.9213867188

Searching for "Osnabrueck, Germany" in PGIS returns the coordinates:
52.267, 8.053

How were the coordinates transformed to metres (i.e. to 5794315.99, 
3435430.596)?
 
> Is there a reasonable explanation for this or did I something wrong?

Could it be an location error problem?
Kind regards, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] global radiation calculated with r.sun seems to be very high

[Frank Reekers]

Thanks for the hint.
I did the calculations with the default value of the linke Linke 
turbidity coeffcient, which is 3.0
In the output table of PVGIS the Linke turbidity coeffcient is in 
february 2.7, so I think this should be okay.

Any other ideas?


Alberto Pettazzi schrieb:
Maybe the problem is due to a Linke turbidity coeffcient too low 
(atmosphere too transparent)...



Frank Reekers escribió:
the global radiation, calculated with r.sun, seems to be very high in 
comparison to PVGIS (Photovoltaic Geographical Information System).

- r.sun for 14. Feb: ~2363 Wh/m² per day
- PVGIS: 1330 Wh/m² per day Irradiation on horizontal plane for 
february on average


Below the detailed steps I did in GRASS and with PVGIS:
1. PVGIS:
a) http://re.jrc.ec.europa.eu/pvgis/apps3/pvest.php -> search for 
location 'Osnabrueck, Germany' -> choose monthly radiation -> click 
calculate -> the output table shows 1330 Wh/m² Irradiation on 
horizontal plane for february.


2. GRASS
a) Take an existing DEM with the resolution of 1m and set all 
z-values to 68m to have a completely horizontal plane:

GRASS 6.4.0RC6 (GRASS)> r.mapcalc dsxx94c68=dsxx...@permanent*0+68.00

b) Set Region
GRASS 6.4.0RC6 (GRASS)> g.region rast=dsxx94c68

c) Create slope & aspect:
GRASS 6.4.0RC6 (GRASS)> r.slope.aspect elevation=dsxx94...@permanent 
slope=sdsxx94c68 aspect=adsxx94c68 --overwrite


d) Run r.sun for day 45:
GRASS 6.4.0RC6 (GRASS)> r.sun elevin=dsxx94...@permanent 
aspin=adsxx94...@permanent slopein=sdsxx94...@permanent 
glob_rad=g45phxx94c68  day=45 --overwrite


e) Get global radiation:
GRASS 6.4.0RC6 (GRASS)> r.what input=g45phxx94c68 
east_north=3435430.596,5794315.99

3435430.596|5794315.99||2362.9213867188


Is there a reasonable explanation for this or did I something wrong?

Thanks for your help
Frank
___
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

[GRASS-user] r.sun Within day hourly calculations

[Roy Sanderson]

Dear Grass-Users

I'm trying to calculate solar radiation (direct or diffuse) over a 30
day period, but need the results broken down into an hourly basis.  It
is only for one specific site (fortunately!).  According to the r.sun
manual, this can easily be done, by running r.sun in a script, linked in
Mode 1 and Mode 2.  However, I'm not clear on how to do this - has
anyone any advice?

Many thanks
Roy

-- 
Roy Sanderson
School of Biology
Devonshire Building
Newcastle University
Newcastle upon Tyne NE1 7RU
r.a.sander...@newcastle.ac.uk
Tel: 0191 246 4835
Fax: 0191 246 4802

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

[GRASS-user] Issues when reprojecting from a GCS to a PCS

[Hanlie Pretorius]

Hi Everyone,

I'm working in GRASS 6.4RC6 on Win XP and am trying to reproject TRMM
rainfall data from its native GCS (WGS84) to a local PCS. I'm using
the PCS because my other important data, specifically DEMs, are
provided in it. TRMM data come in 0.25°x0.25° squares.

My workfow is as follows:

1. Import the TRMM data into a WGS84 location using r.in.xyz. This
gives a raster with the following information:

 ++
 | Layer:3b42.00021...@permanentDate: Thu Jul 15 14:42:27 2010
 | Mapset:   PERMANENT  Login of Creator: hanlie
 | Location: world_wgs84
 | DataBase: F:\Hanlie\grassdata
 | Title:Raw x,y,z data binned into a raster grid by cell mean ( 3B42.000
 | Timestamp: none
 |---
 |
 |   Type of Map:  raster   Number of Categories: 255
 |   Data Type:FCELL
 |   Rows: 6
 |   Columns:  3
 |   Total Cells:  18
 |Projection: Latitude-Longitude
 |N: 27:15SS: 28:45S   Res:  0:15
 |E: 28:45EW:28E   Res:  0:15
 |   Range of data:min = 0.00  max = 0.070614
 |
 |   Data Source:
 |F:\Hanlie\UCT\M.Sc\Data\TRMM\2000\02_Februarie\3B42.000215.0.6.nc.lieb.
 |
 |
 |   Data Description:
 |generated by r.in.xyz
 |
 |   Comments:
 |r.in.xyz input="F:\Hanlie\UCT\M.Sc\Data\TRMM\2000\02_Februarie\3B42.\
 |000215.0.6.nc.lieb.txt" output="3B42.000215.0" method="mean" type="F\
 |CELL" x=2 y=1 z=3 zscale=1.0 percent=100
 |
 ++

2. Set the region to this raster file and create a vector map from it
using v.in.region. This gives a vector with the following information:

 ++
 | Layer:   lieb_trmm_reg...@permanent
 | Mapset:  PERMANENT
 | Location:world_wgs84
 | Database:F:\Hanlie\grassdata
 | Title:
 | Map scale:   1:1
 | Map format:  native
 | Name of creator: hanlie
 | Organization:
 | Source date: Thu Jul 15 14:55:13 2010
 ||
 |   Type of Map:  vector (level: 2)
 |
 |   Number of points:   0   Number of areas:  1
 |   Number of lines:0   Number of islands:1
 |   Number of boundaries:   1   Number of faces:  0
 |   Number of centroids:1   Number of kernels:0
 |
 |   Map is 3D:  No
 |   Number of dblinks:  0
 |
 | Projection: Lat/Lon
 |   N:27:15SS:28:45S
 |   E:28:45EW:   28E
 |
 |   Digitization threshold: 0
 |   Comments:
 |
 ++

3. Change to the PCS location and reproject the TRMM region using
v.proj. This gives a vector with the following information:

 ++
 | Layer:   lieb_trmm_reg...@permanent
 | Mapset:  PERMANENT
 | Location:sa_tm_29deg_E
 | Database:F:\Hanlie\grassdata
 | Title:
 | Map scale:   1:1
 | Map format:  native
 | Name of creator: hanlie
 | Organization:
 | Source date: Thu Jul 15 14:55:13 2010
 ||
 |   Type of Map:  vector (level: 2)
 |
 |   Number of points:   0   Number of areas:  1
 |   Number of lines:0   Number of islands:1
 |   Number of boundaries:   1   Number of faces:  0
 |   Number of centroids:1   Number of kernels:0
 |
 |   Map is 3D:  No
 |   Number of dblinks:  0
 |
 | Projection: Transverse Mercator
 |   N: -3015356.39959204S: -3181970.90748457
 |   E:-24418.1519951W:   -99037.39660484
 |
 |   Digitization threshold: 0
 |   Comments:
 |
 ++

4. Set the region of the PCS to the TRMM region:

g.region -p vect=lieb_trmm_reg...@permanent nsres=25 ewres=25

which gives:

projection: 99 (Transverse Mercator)
zone:   0
datum:  ** unknown (default: WGS84) **
ellipsoid:  wgs84
north:  -3015356.39959204
south:  -3181970.90748457
west:   -99037.39660484
east:   -24418.1519951
nsres:  24.99842579
ewres:  24.9980719
rows:   6665
cols:   2985
cells:  19895025


I use this resolution because I don't really know what else to use.
When I reproject the TRMM GRID into the PCS, I get polygons with
differing areas, so I can't use the TRMM grid size as resolution:

v.report map=lieb_trmm_squa...@permanent option=area units=kilometers
Displaying column types/nam

[GRASS-user] DBMI-DBF driver error

[Sandile Gumede]

Hi

Can anyone help me on this problem?

On Wed, Jul 14, 2010 at 1:31 PM, Sandile Gumede wrote:

> Hi,
>
> I'm using GTOPO30 DEM data and TRMM (rainfall) data, I selected the data
> for the whole of africa but I'm getting an error when executing
> v.rast.stats.
>
> Here is a step-by-step of what I did:
>
> 1. GTOPO30 DEM
>- downloaded e020n10,w020s10,e020n40,w020n40 compressed files from "
> ftp://edcftp.cr.usgs.gov/pub/data/gtopo30/global/";.
>- decompressed all the above files.
>- Added "PIXELTYPE SIGNEDINT" in all .HDR files
>- warp merged all the .DEM file with  "gdalwarp *.DEM Africa.tif"
> command.
>- projected it with "gdal_translate -a_srs EPSG:4326  Africa.tif
> DEM.tif"
>
> 2. TRMM "rainfall" data
>   - downloaded 3B42RT.2010061503.1day.tif,3B42RT.2010061503.1day.tfw
> from "".
>   - projected it with "gdal_translate -a_srs EPSG:4326 -projwin -20 40
> 60 -60 3B42RT.2010061503.1day.tif TRMM.tif ".
>
> Then, imported the two data sets:
>
> r.in.gdal in=/home/tgumede1/grassdem/ict4eo/DEM.tif out=dem
>
> Projection of input dataset and current location appear to match
>  100%
> r.in.gdal complete. Raster map  created.
>
> g.region rast=dem
>
> r.in.gdal in=/home/tgumede1/grassdem/ict4eo/CapeTown_TRMMs.tif out=rainfall
> target=CapeTown
>
> Projection of input dataset and current location appear to match
>  100%
> r.in.gdal complete. Raster map  created.
>
> r.watershed elevation=dem accumulation=acc drainage=direction stream=str
> basin=catch memory=300 threshold=10
>
> SECTION 1a (of 5): Initiating Memory.
> SECTION 1b (of 5): Determining Offmap Flow.
>  100%
> SECTION 2: A * Search.
>  100%
> SECTION 3: Accumulating Surface Flow.
>  100%
> SECTION 4: Watershed determination.
>  100%
> SECTION 5: Closing Maps.
>  100%
>
>   Q: How do one really know the exact threshold value?
>
> r.to.vect in=catch out=catchments feature=area
>
> Extracting areas...
>  100%
>  100%
> Building topology for vector map ...
> Registering primitives...
> 134246 primitives registered
> 701002 vertices registered
> Building areas...
>  100%
> 44645 areas built
>
> 1 isles built
> Attaching islands...
>  100%
> Attaching centroids...
>  100%
> Number of nodes: 89602
> Number of primitives: 134246
>
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 89604
> Number of centroids: 44642
> Number of areas: 44645
> Number of isles: 1
> Number of areas without centroid: 3
> r.to.vect complete.
>
>
> g.region rast=rainfall
>
> v.rast.stats vector=catchments raster=rainfall colprefix=precip
> WARNING: Area without centroid (may be OK for island)
> WARNING: Area without centroid (may be OK for island)
> WARNING: Area without centroid (may be OK for island)
>
> DBMI-DBF driver error:
> SQL parser error: syntax error, unexpected NULL_VALUE processing 'NULL'
> in statement:
> UPDATE catchments SET precip_cf_=-NULL WHERE cat=17
>
> Error in db_execute_immediate()
>
> ERROR: Error while executing: 'UPDATE catchments SET precip_cf_=-NULL WHERE
>cat=17'
>
>
> - output of r.info -g
>
> r.info -g rainfall
> north=40
> south=-60
> east=60
> west=-20
>
> - output of v.info
>
> v.info -g catchments
> north=40
> south=-60
> east=60
> west=-20
>
> top=0.00
> bottom=0.00
>
> output of r.info
>
> Type of Map:  raster   Number of Categories: 2559
> Data Type:
> CELL
> Rows:
> 400
> Columns:
> 320
> Total Cells:
> 128000
>  Projection:
> Latitude-Longitude
>  N:40NS:60S   Res:
> 0:15
>  E:60EW:20W   Res:
> 0:15
> Range of data:min = 0  max =
> 2559
>
>
> Data
> Description:
>  generated by
> r.in.gdal
>
>
>
> Comments:
>  r.in.gdal input="/home/tgumede1/grassdem/ict4eo/CapeTown_TRMMs.tif"
> \
>  output="rainfall" target="CapeTown"
>
>
> - output of r.univar
>
> r.univar rainfall
>  100%
> total null and non-null cells: 11520
>
> total null cells: 0
>
> Of the non-null cells:
> --
> n: 11520
> minimum: 0
> maximum: 2559
> range: 2559
> mean: 22.4897
> mean of absolute values: 22.4897
> standard deviation: 83.1312
> variance: 6910.79
> variation coefficient: 369.642 %
> sum: 2590809300
>
>
>
>
>
>
> --
> Kind Regards
> TS Gumede
> CSIR, Meraka Institute
> 072 258 1650
>
>


-- 
Kind Regards
TS Gumede
CSIR, Meraka Institute
072 258 1650
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: v.rast.stats

[Micha Silver]

On 15/07/2010 09:57, Sandile Gumede wrote:
Hi Micha
  
Which DEM data you used to test this rainfall data?
  
Can I have it?

I did the exercise below based on the ASTER DEM data from the US JPL
program.
You can download data for anywhere in the world, at 30 m. resolution,
from:
https://wist.echo.nasa.gov/~wist/api/imswelcome/
It requires registering, then after you manage to login, type ASTER DEM
in the keyword search. Next scroll down to the Search Area section, and
select one of the methods to mark the region you want. Eventually
you'll be able to finish the query and they send you an email that the
search has completed, with a download link to get the data.


  On Sat, Jun 19, 2010
at 9:57 PM, Micha Silver  wrote:
  

Hello Sandile:
I tried to duplicate your steps and it seems to work for me.
Here's what I did:


wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw


gdalinfo 3B42RT.2010032900.1day.tif
Driver: GTiff/GeoTIFF
Files: 3B42RT.2010032900.1day.tif
   3B42RT.2010032900.1day.tfw
Size is 1440, 480
Coordinate System is `'
Origin = (-180.000,60.000)
Pixel Size = (0.250,-0.250)


 Note: no projection info above 

 Now I use the -projwin option of gdal_translate to select a small
window 
gdal_translate -a_srs EPSG:4326 -projwin 34.0 33.0 36.0 29.0
3B42RT.2010032900.1day.tif rainfall_il.tif

 GEOGCS entry now shows 4326 

g.mapset map=ASTER_DEM loc=WGS84  
- A location setup as EPSG:4326

r.in.gdal israel.tif out=rainfall_il

r.univar rainfall_il
 100%
total null and non-null cells: 7776

total null cells: 0

Of the non-null cells:
--

n: 7776
minimum: 0
maximum: 34
range: 34
mean: 0.364583
mean of absolute values: 0.364583
standard deviation: 3.45241
variance: 11.9192
variation coefficient: 946.948 %
sum: 2835


- Now using an existing catchment vector map 
v.rast.stats vect=arava_wsheds rast=rainfall_il colpre=precip
v.info
-c arava_wsheds
Displaying column types/names for database connection of layer 1:
INTEGER|cat
CHARACTER|label
DOUBLE PRECISION|area_km
INTEGER|precip_n
DOUBLE PRECISION|precip_min
DOUBLE PRECISION|precip_max
DOUBLE PRECISION|precip_range
DOUBLE PRECISION|precip_mean
DOUBLE PRECISION|precip_stddev
DOUBLE PRECISION|precip_variance
DOUBLE PRECISION|precip_cf_var
DOUBLE PRECISION|precip_sum

 and some values 

v.db.select arava_wsheds 
cat|label|area_km|precip_n|precip_min|precip_max|precip_range|precip_mean|precip_stddev|precip_variance|precip_cf_var|precip_sum
21|Jordan|1055.231692|2|0|0|0|0|0|0||0
19|Hidan|987.811979|2|0|0|0|0|0|0||0
28|Og|124.122969|
36|Zarqa|273.606213|
24|Kidron|122.460114|
9|Darga|289.012122|
6|Arugot|236.365116|1|0|0|0|0|0|0||0
26|Mujib|1277.546513|2|0|0|0|0|0|0||0

 (Many catchments have 0 or no value because of the small region I
chose. The global data is 1/4 degree resolution and my region is only 2
deg E-W.)

HTH...
-- 
Micha




On 06/17/2010 12:50 PM, Sandile Gumede wrote:
Hi
  
It is still giving me -NULL value error.
  
Do you think maybe its the way I downloaded my rainfall data? This is
the site where I downloaded my data sets ftp://trmmopen.gsfc.nasa.gov/pub/gis/
  and this data covers the whole world, the only thing I did
was to
clip a specific region (using coordinates) that is in South Africa to
do my analysis. I used a bash script to download and project the data,
see below:
  
  
#!/bin/bash
  
wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw
  
gdal_translate -of GTiff -co "PROFILE="" -co "INTERLEAVE=PIXEL"
-co "COMPRESS=LZW" -co "TILED=YES" -a_srs EPSG:4326 -a_ullr 18.2987501
-33.6795831 19.1712501 -34.3487498 3B42RT.2010032900.1day.tif
TRMMLast1day.tif
  
  
  
  
  On Thu, Jun 17,
2010 at 8:41 AM, Sandile
Gumede 
wrote:
  Hi

It is still giving me -NULL value error.

Do you think maybe its the way I downloaded my rainfall data? This is
the site where I downloaded my data sets ftp://trmmopen.gsfc.nasa.gov/pub/gis/
and this data covers the whole world, the only thing I did
was
to clip a specific region (using coordinates) that is in South Africa
to do my analysis. I used a bash script to download and project the
data, see below:


#!/bin/bash

wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw

gdal_translate -of GTiff -co "PROFILE="" -co "INTERLEAVE=PIXEL"
-co "COMPRESS=LZW" -co "TILED=YES" -a_srs EPSG:4326 -a_ullr 18.2987501
-33.6795831 19.1712501 -34.3487498 3B

Re: [GRASS-user] global radiation calculated with r.sun seems to be very high

[Alberto Pettazzi]

Maybe the problem is due to a Linke turbidity coeffcient too low 
(atmosphere too transparent)...



Frank Reekers escribió:
the global radiation, calculated with r.sun, seems to be very high in 
comparison to PVGIS (Photovoltaic Geographical Information System).

- r.sun for 14. Feb: ~2363 Wh/m² per day
- PVGIS: 1330 Wh/m² per day Irradiation on horizontal plane for 
february on average


Below the detailed steps I did in GRASS and with PVGIS:
1. PVGIS:
a) http://re.jrc.ec.europa.eu/pvgis/apps3/pvest.php -> search for 
location 'Osnabrueck, Germany' -> choose monthly radiation -> click 
calculate -> the output table shows 1330 Wh/m² Irradiation on 
horizontal plane for february.


2. GRASS
a) Take an existing DEM with the resolution of 1m and set all z-values 
to 68m to have a completely horizontal plane:

GRASS 6.4.0RC6 (GRASS)> r.mapcalc dsxx94c68=dsxx...@permanent*0+68.00

b) Set Region
GRASS 6.4.0RC6 (GRASS)> g.region rast=dsxx94c68

c) Create slope & aspect:
GRASS 6.4.0RC6 (GRASS)> r.slope.aspect elevation=dsxx94...@permanent 
slope=sdsxx94c68 aspect=adsxx94c68 --overwrite


d) Run r.sun for day 45:
GRASS 6.4.0RC6 (GRASS)> r.sun elevin=dsxx94...@permanent 
aspin=adsxx94...@permanent slopein=sdsxx94...@permanent 
glob_rad=g45phxx94c68  day=45 --overwrite


e) Get global radiation:
GRASS 6.4.0RC6 (GRASS)> r.what input=g45phxx94c68 
east_north=3435430.596,5794315.99

3435430.596|5794315.99||2362.9213867188


Is there a reasonable explanation for this or did I something wrong?

Thanks for your help
Frank
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  



--

Alberto Pettazzi


MeteoGalicia - Departamento de Climatología y Observación

Consellería de Medio Ambiente, Territorio e Infraestruturas

Rúa de Roma, 6

15707 Santiago de Compostela. A Coruña


Teléfono: +34-881-999646


e-mail: alberto.petta...@meteogalicia.es 




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

[GRASS-user] global radiation calculated with r.sun seems to be very high

[Frank Reekers]

the global radiation, calculated with r.sun, seems to be very high in 
comparison to PVGIS (Photovoltaic Geographical Information System).

- r.sun for 14. Feb: ~2363 Wh/m² per day
- PVGIS: 1330 Wh/m² per day Irradiation on horizontal plane for 
february on average


Below the detailed steps I did in GRASS and with PVGIS:
1. PVGIS:
a) http://re.jrc.ec.europa.eu/pvgis/apps3/pvest.php -> search for 
location 'Osnabrueck, Germany' -> choose monthly radiation -> click 
calculate -> the output table shows 1330 Wh/m² Irradiation on horizontal 
plane for february.


2. GRASS
a) Take an existing DEM with the resolution of 1m and set all z-values 
to 68m to have a completely horizontal plane:

GRASS 6.4.0RC6 (GRASS)> r.mapcalc dsxx94c68=dsxx...@permanent*0+68.00

b) Set Region
GRASS 6.4.0RC6 (GRASS)> g.region rast=dsxx94c68

c) Create slope & aspect:
GRASS 6.4.0RC6 (GRASS)> r.slope.aspect elevation=dsxx94...@permanent 
slope=sdsxx94c68 aspect=adsxx94c68 --overwrite


d) Run r.sun for day 45:
GRASS 6.4.0RC6 (GRASS)> r.sun elevin=dsxx94...@permanent 
aspin=adsxx94...@permanent slopein=sdsxx94...@permanent 
glob_rad=g45phxx94c68  day=45 --overwrite


e) Get global radiation:
GRASS 6.4.0RC6 (GRASS)> r.what input=g45phxx94c68 
east_north=3435430.596,5794315.99

3435430.596|5794315.99||2362.9213867188


Is there a reasonable explanation for this or did I something wrong?

Thanks for your help
Frank
<>___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] v.rast.stats

[Sandile Gumede]

Hi Micha

Which DEM data you used to test this rainfall data?

Can I have it?

Can you also post the steps you did, maybe I'm missing something?


On Sat, Jun 19, 2010 at 9:57 PM, Micha Silver  wrote:

>  Hello Sandile:
> I tried to duplicate your steps and it seems to work for me.
> Here's what I did:
>
> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw
>
> gdalinfo 3B42RT.2010032900.1day.tif
> Driver: GTiff/GeoTIFF
> Files: 3B42RT.2010032900.1day.tif
>3B42RT.2010032900.1day.tfw
> Size is 1440, 480
>
> Coordinate System is `'
> Origin = (-180.000,60.000)
> Pixel Size = (0.250,-0.250)
> 
>
>  Note: no projection info above 
>
>  Now I use the -projwin option of gdal_translate to select a small
> window
> gdal_translate -a_srs EPSG:4326 -projwin 34.0 33.0 36.0 29.0
> 3B42RT.2010032900.1day.tif rainfall_il.tif
>
>  GEOGCS entry now shows 4326 
>
> g.mapset map=ASTER_DEM loc=WGS84
> - A location setup as EPSG:4326
>
> r.in.gdal israel.tif out=rainfall_il
>
> r.univar rainfall_il
>  100%
> total null and non-null cells: 7776
>
> total null cells: 0
>
> Of the non-null cells:
> --
> n: 7776
> minimum: 0
> maximum: 34
> range: 34
> mean: 0.364583
> mean of absolute values: 0.364583
> standard deviation: 3.45241
> variance: 11.9192
> variation coefficient: 946.948 %
> sum: 2835
>
>
> - Now using an existing catchment vector map 
> v.rast.stats vect=arava_wsheds rast=rainfall_il colpre=precip
> v.info -c arava_wsheds
> Displaying column types/names for database connection of layer 1:
> INTEGER|cat
> CHARACTER|label
> DOUBLE PRECISION|area_km
> INTEGER|precip_n
> DOUBLE PRECISION|precip_min
> DOUBLE PRECISION|precip_max
> DOUBLE PRECISION|precip_range
> DOUBLE PRECISION|precip_mean
> DOUBLE PRECISION|precip_stddev
> DOUBLE PRECISION|precip_variance
> DOUBLE PRECISION|precip_cf_var
> DOUBLE PRECISION|precip_sum
>
>  and some values 
>
> v.db.select arava_wsheds
>
> cat|label|area_km|precip_n|precip_min|precip_max|precip_range|precip_mean|precip_stddev|precip_variance|precip_cf_var|precip_sum
> 21|Jordan|1055.231692|2|0|0|0|0|0|0||0
> 19|Hidan|987.811979|2|0|0|0|0|0|0||0
> 28|Og|124.122969|
> 36|Zarqa|273.606213|
> 24|Kidron|122.460114|
> 9|Darga|289.012122|
> 6|Arugot|236.365116|1|0|0|0|0|0|0||0
> 26|Mujib|1277.546513|2|0|0|0|0|0|0||0
>
>  (Many catchments have 0 or no value because of the small region I
> chose. The global data is 1/4 degree resolution and my region is only 2 deg
> E-W.)
>
> HTH...
> --
> Micha
>
>
> On 06/17/2010 12:50 PM, Sandile Gumede wrote:
>
> Hi
>
> It is still giving me -NULL value error.
>
> Do you think maybe its the way I downloaded my rainfall data? This is the
> site where I downloaded my data sets*
> ftp://trmmopen.gsfc.nasa.gov/pub/gis/ *and this data covers the whole
> world, the only thing I did was to clip a specific region (using
> coordinates) that is in South Africa to do my analysis. I used a bash script
> to download and project the data, see below:
>
>
> #!/bin/bash
>
> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw
>
> gdal_translate -of GTiff -co "PROFILE=GeoTIFF" -co "INTERLEAVE=PIXEL" -co
> "COMPRESS=LZW" -co "TILED=YES" -a_srs EPSG:4326 -a_ullr 18.2987501
> -33.6795831 19.1712501 -34.3487498 3B42RT.2010032900.1day.tif
> TRMMLast1day.tif
>
>
>
>
> On Thu, Jun 17, 2010 at 8:41 AM, Sandile Gumede wrote:
>
>> Hi
>>
>> It is still giving me -NULL value error.
>>
>> Do you think maybe its the way I downloaded my rainfall data? This is the
>> site where I downloaded my data sets*
>> ftp://trmmopen.gsfc.nasa.gov/pub/gis/ *and this data covers the whole
>> world, the only thing I did was to clip a specific region (using
>> coordinates) that is in South Africa to do my analysis. I used a bash script
>> to download and project the data, see below:
>>
>>
>> #!/bin/bash
>>
>> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tif
>> wget ftp://trmmopen.gsfc.nasa.gov/pub/gis/3B42RT.2010032900.1day.tfw
>>
>> gdal_translate -of GTiff -co "PROFILE=GeoTIFF" -co "INTERLEAVE=PIXEL" -co
>> "COMPRESS=LZW" -co "TILED=YES" -a_srs EPSG:4326 -a_ullr 18.2987501
>> -33.6795831 19.1712501 -34.3487498 3B42RT.2010032900.1day.tif
>> TRMMLast1day.tif
>>
>>
>>
>>  2010/6/15 Micha Silver 
>>
>>>  On 15/06/2010 14:35, Sandile Gumede wrote:
>>>
>>> Hi
>>> If I run g.region rast=rainfall -p, I get:
>>>
>>>   OK, what you've done here is change the current region to match the
>>> raster "rainfall".
>>> Can you now try:
>>> v.rast.stats -c vect=catchments rast=rainfall pref=precip
>>>
>>>
>>>
>>>
>>> projection: 3 (Latitude-Longitude)
>>> zone:   0
>>> datum:  wgs84
>>> ellipsoid:  wgs84
>>> north:  33:40:46.49916S
>>> south: