headers
Hamish | 1 Dec 2006 01:07
X-Face
Picon
Favicon

Re: [GRASS-user] Clarification on units used in r.sun

Dylan Beaudette wrote:
> 
> I was aware of the Joule - Watt relationship, but was not quite sure
> why r.sun  was using W*h instead of Joules. Since a Mega-Joule is a
> much more readily used unit of enery, I think that I will do the
> conversion from now on.

It is my understanding that W/m2 is the standard unit used by the solar
modelling community.

The other common one that our LI-COR PAR sensors are calibrated with is
micro-mol . s-1 . m-2.  (aka einsteins, or photon quanta)

I suggest having a look through the literature and manuals here:
  http://www.licor.com/env/Products/Sensors/rad.jsp

Starting with:
  http://www.licor.com/env/PDF_Files/Rad_Meas.pdf

It is well written, informative, and clear.

> The next question, pardon my ignorance, is: how to interpret hourly
> averaged insolation (beam + diffuse) values from a weather station,
> which are reported in W/(m^2) ?
>
> Is this essentially this same thing, as it is "integrated" over an
> hour when summed for the entire day?

I would guess sum midnight to midnight hourly averages of W/m2 = mode2 ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
CARLOS TORRES | 1 Dec 2006 01:23
Picon
Favicon

[GRASS-user] ortofoto



hola tengo problemas al crear una otrofoto pues las guias que se encuentran en la pagina de grass no son muy claras para mi alguien tiene algun manual con procedimiento mas claro que me pueda ayudar




 

que pases un buen dia gracias por confiar en nosotros

 

 

 

Carlos Torres Buelvas


Éxitos, grandes clásicos y novedades. Un millón de canciones en MSN Music. 
_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 0 comments |
headers
Hamish | 1 Dec 2006 01:40
X-Face
Picon
Favicon

Re: [GRASS-user] can r.in.xyz get input from STDIN?

Ken wrote:
> i'm getting xyz data from the grass command prompt using a query like:
> echo "select x,y,z from...." | db.select  > outfile.xyz
> 
> then reading into grass using:
> r.in.xyz input=outfile.xyz ....
> 
> just wondering if i can do this in one step by piping my select output
> directly into r.in.xyz?
> 
> (i suppose i could just right a wrapper script to do this if i can't
> do it directly)

No, you can't right now. But it is a planned feature.  (input="-")

This would have the advantage of bypassing any LFS problems. (?)
The only (minor) problem I see is that data taken from stdin would
obviously have to bypass the G_percent() calls (that's ok) but as a
replacement I'd like to use G_clicker(), and I'm not sure how well the
GUI version will deal with that. (would need some help from a Tcl expert)

Hamish

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 3 comments |
headers
Hamish | 1 Dec 2006 01:46
X-Face
Picon
Favicon

Re: [GRASS-user] Importing a SDTS/DLG files?

Tom Russo wrote:
> > SDTS files contain several tables with no geometry (OGR calls them
> > "Layers") that probably confuse v.in.ogr, and also contain point,
> > line, and polygon features.  My guess is that v.in.ogr doesn't quite
> > grok which things it needs to ignore.
> > 
> > When I do an ogrinfo on an SDTS road file I see:
> > > ogrinfo TR01CATD.DDF 
> > ERROR 4: SDTS Driver doesn't support update.
> > Had to open data source read-only.
> > INFO: Open of `TR01CATD.DDF'
> >       using driver `SDTS' successful.
> > 1: ARDF (None)
> > 2: ARDM (None)
> > 3: AHDR (None)
> > 4: NP01 (Point)
> > 5: NA01 (Point)
> > 6: NO01 (Point)
> > 7: LE01 (Line String)
> > 8: PC01 (Polygon)
> > 
> > I bet if you were to use a "layer=NO01,LE01,PC01" option to v.in.ogr
> > your woes would go away.  In fact, when I try to import the very
> > same SDTS file above, it worked fine and gave line, point, and
> > polygon features; the vector map displays Just Fine.
> 
> That particular choice of "layers" is appropriate for SDTS files that
> contain  only polylines (such as road layers), but not for anything
> that contains  meaningful polygons --- if you tried to use this on,
> say, a surface cover layer all the attributes of the polygons would be
> missing because those are in the centroids from the NA "module" (which
> is the SDTS terminology).  To  get polygons with attributes you'll
> need to attach centroids to the polygons,  and those are in the NA
> module.  You'll need to use the "type=" option to  v.in.ogr to read in
> "layers" with the right types.  I'm not exactly sure how  to do that,
> although I think I can guess:
> 
>   v.in.ogr dsn=<catd file> layer=NO01,LE01,PC01,NA01
>   type=point,line,boundary,centroid output=...
> 
> If I read the v.in.ogr help correctly, that should import the NO01 
> module/"layer" as points, the LE01 module/"layer" as polylines, the
> PC01 "layer" as boundaries, and the NP01 "layer" as area centroids. 
> But someone more knowledgable should step in and correct me.

this sounds like the basis for a nice "v.in.sdts" script for GRASS 6.

Hamish

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 1 comment |
headers
Hamish | 1 Dec 2006 01:51
X-Face
Picon
Favicon

Re: [GRASS-user] AAIGrid import-export problem

Martin Wegmann wrote:
> On Thursday 30 November 2006 13:43, Wolfgang wrote:
> > have you changed g.region to your new settings before export?
> 
> I changed g.region res. during the r.resamp.stats but for export of
> the two raster g.region wasn't changed
> 
> BTW r.info of the two raster gives same res/coord. for both.

what about with using the new region sensitive GDAL output? (resamples)
"r.out.gdal -r"

r.in.gdal out=NAME
g.region rast=NAME
r.out.gdal -r in=NAME

?
Hamish

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 3 comments |
headers
Hamish | 1 Dec 2006 05:00
X-Face
Picon
Favicon

Re: [GRASS-user] interpolating data points

Michael Perdue wrote:
> GRASS 6.2.0 (newLocation):~ > g.region n=50:15:00N s=49:15:00N  \
>   e=110:15:00W w=111:45:00W nsres=00:30:00 ewres=00:30:00

tip:

for lat/lon positions, you can often leave off trailing ":00"

e.g. for 45S lat:
 -45.000, 45S, 45:00S, 45:00:00S, and 45:00:00.000S should all work.

in GRASS 6.2+ decimal minutes should work too. (45:00.000S)

might save you a few keystrokes or conversion steps.

Hamish

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 0 comments |
headers
Dylan Beaudette | 1 Dec 2006 06:06
Picon

Re: [GRASS-user] Clarification on units used in r.sun

On 11/30/06, Hamish <hamish_nospam <at> yahoo.com> wrote:
> Dylan Beaudette wrote:
> >
> > I was aware of the Joule - Watt relationship, but was not quite sure
> > why r.sun  was using W*h instead of Joules. Since a Mega-Joule is a
> > much more readily used unit of enery, I think that I will do the
> > conversion from now on.
>
> It is my understanding that W/m2 is the standard unit used by the solar
> modelling community.
>
> The other common one that our LI-COR PAR sensors are calibrated with is
> micro-mol . s-1 . m-2.  (aka einsteins, or photon quanta)
>
> I suggest having a look through the literature and manuals here:
>   http://www.licor.com/env/Products/Sensors/rad.jsp
>
> Starting with:
>   http://www.licor.com/env/PDF_Files/Rad_Meas.pdf
>
> It is well written, informative, and clear.
>
>
> > The next question, pardon my ignorance, is: how to interpret hourly
> > averaged insolation (beam + diffuse) values from a weather station,
> > which are reported in W/(m^2) ?
> >
> > Is this essentially this same thing, as it is "integrated" over an
> > hour when summed for the entire day?
>
> I would guess sum midnight to midnight hourly averages of W/m2 = mode2 ?
>

Right-- this was what I had been *assumming* unitl now :)
... but after getting some odd results I decided to ask around.

With respect to a previous email about odd results from r.sun : I
think that was caused by an operator error, and will post a reply to
myself in order to clear Jaro, et al. :) .

Dylan

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 0 comments |
headers
Hamish | 1 Dec 2006 07:13
X-Face
Picon
Favicon

[GRASS-user] Re: [GRASS-dev] Changes to r.sun made Feb 2006 [resolved]

Dylan Beaudette wrote:
> PS: with even better results from r.sun:
> http://169.237.35.250/~dylan/temp/11-yr_variation_vs_modeled.png
> 
> when using longer term averages, the R^2 goes to 0.95 ! (right hand
> sub-figure), but still working on optimal Linke turbidity values.

Did you extract the Linke turbidity values from the app. on the EU web
site, derive it from measured in situ values, or are you tweaking that
variable as a calibration to get r.sun to match your measured radiation
values?

I see you have a bit of sawtooth noise in your plots. FWIW to avoid
introducing this monthly jump I wrote a little app some time ago which
interpolated daily Linke value from the monthly Linke averages (for use
in r.sun bash script loop) [assume monthly averages are for day 15 of
each month and interpolate for the days in between]. I'd have to dig it
out, & it's probably a mix of Matlab+C. Maybe something for the wiki
add-ons.

How to deal with cloud cover? (coefbh= and coefdh=) Use real clear-day
measured data (find a day with a clean curve) to estimate the cloud
attenuation factors for neighboring cloudy days (theoretical curve vs
what actually happened), then generalize the cloudiness factor over your
decade long dataset?  e.g. find max (midday) light for each year's day
90, then take the max. maybe include +/-1 day. then run a smoothing
filter on the result. ?? probably want the coeffs to vary throughout
the year.

Another idea I've been playing with is getting cloud cover data from
recorded PV voltage in one of our remote solar-powered weather stations
(it lacks a real light meter). There's a pretty obvious pattern in the
voltage signal to play with. Just a matter of calibrating it..

Hamish

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 17 comments |
headers
José Antonio Ruiz Arias | 1 Dec 2006 09:14
Picon
Favicon

RE: [GRASS-user] Clarification on units used in r.sun

Hi Dylan,

 

Probably you have cleared your doubt but I'll try to expound how I see the question. The most important thing is you firstly have to think if you are dealing with flux or energy.

 

The flux is something (let say, particles or light photons) coming through a normal surface to the beam (for example, persons through a door). Therefore the unit of flux has to be something like particles per squared meter and per second (how many particles have reached the normal surface in a second). In case of light (photons) we talk in terms of energy to count the particles, so we have J/m2*s = W/m2 (because W = J/s). Then, when you measure the solar radiation with a sensor, the measurement is usually in units of flux [W/m2]. What does it mean? Let suppose in a given moment the sensor reads 500 W/m2. That equals to 500 J/s/m2 = 500 J/m2/s, i.e. in a second you have received 500 Joules per squared meter so, in 2 seconds, you will have 1000 joules in a squared meter. In 3 seconds you will have 1500 joules in a squared meter and so on. Now we have sum (or integrated) the flux throw the time and the magnitude can be seen as energy per unit of surface in a certain period of time, let say hour, day, month,…

 

Watts per hour is a measurement of energy used in engineering not in science. The only reason I think is because the magnitude of its value is more appropriate than J or MJ. The equivalence is 1 Wh = (1 J/s)*3600 s = 3600 J = 0.0036 MJ

 

I work with radiometric sensors and sometimes I have used r.sun. The approach I follow is to express both in J/m2/dia. With r.sun the output is in Wh/m2/dia so directly multiply by 0.0036 and you will have MJ/m2/dia and will know how much energy you have in a squared meter when the day finish. Now let suppose you are getting a measurement every 10 minutes, i.e. every 600 seconds. In that lapse of time you will have S[W/m2]*600seconds, where S is the measurement. In a day you will have Sday[J/m2/dia] = S1*600s + S2*600s + S3*600s + … and so on for all measurements in the day.

 

________________________________

 

José A. Ruiz Arias

Departamento de Física

Escuela Politécnica Superior

Edificio A-3, Campus Lagunillas

Universidad de Jaén

23071 Jaén Spain

Tlf. +34 953212474

Email:  jararias <at> ujaen.es

_____________________________________

 

> -----Mensaje original-----

> De: grassuser-bounces <at> grass.itc.it [mailto:grassuser-bounces <at> grass.itc.it]

> En nombre de Dylan Beaudette

> Enviado el: jueves, 30 de noviembre de 2006 22:55

> Para: Glynn Clements

> CC: grassuser <at> grass.itc.it; GRASS devel

> Asunto: Re: [GRASS-user] Clarification on units used in r.sun

>

> On Wednesday 29 November 2006 12:31, Glynn Clements wrote:

> > Dylan Beaudette wrote:

> > > Quick question on the units used for the ouput of r.sun in mode 2

> (daily

> > > sums):

> > >

> > > In the manual pages for r.sun, the following 'unit' is included in the

> > > description:

> > > ----------------------------

> > > The solar radiation maps for given day are computed integrating the

> > > relevant irradiance between sunrise and sunset times for given day.

> The

> > > user can set finer or coarser time step step used for all-day

> radiation

> > > calculations. A default value of step is 0.5 hour. Larger steps (e.g.

> > > 1.0-2.0) can speed-up calculations but produce less reliable results.

> The

> > > output units are in Wh per squared meter per given day [Wh/(m*m)/day].

> > > -------------------------

> > >

> > > Is one to interpret this as "watt-hour per square meter per day" ?

> > > This would seem a little odd, as the the unit 'watt-hour' is not an SI

> > > unit.

> >

> > More odd (to me) is having (different) units of time in both the

> > numerator and denominator. I would have thought it more logical to

> > divide the result by 24 to give Watts per square metre [W/(m^2)].

>

> I need to check with some local experts, but judging from some recent

> tests -

> the output from r.sun is comparible to that from a weather station, with

> *hourly* averaged data in W/(m^2) which i think is analogous to the

> Wh/(m^2)

> units that r.sun uses.

>

> --

> Dylan Beaudette

> Soils and Biogeochemistry Graduate Group

> University of California at Davis

> 530.754.7341

>

> _______________________________________________

> grassuser mailing list

> grassuser <at> grass.itc.it

> http://grass.itc.it/mailman/listinfo/grassuser

>

> __________ Información de NOD32 1894 (20061130) __________

>

> Este mensaje ha sido analizado con  NOD32 antivirus system

> http://www.nod32.com

 

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 4 comments |
headers
Raymond Fu | 1 Dec 2006 13:39
Picon
Favicon

[GRASS-user] 'ARNing: Cannot open driver 'dbf"

I have installed GRASS 6.1 CVS and using the grass61.bat.  However when
I run certain DB related command like g.copy, it also returns 
":No such driver available
'ARNing: Cannot open driver 'dbf"
do I need to do something in the GRASS settings?
 
Thanks
 
Raymond

Send instant messages to your online friends http://uk.messenger.yahoo.com 

_______________________________________________
grassuser mailing list
grassuser <at> grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Permalink | Reply | 13 comments |

Gmane