date:20120103

Re: [GRASS-user] Difference in sunset/sunrise time between r.sun and r.sunmask

2012-01-03 Thread thomas . huld

Hello,

Sorry for the late reply, I tried to send this once but something must have 
gone wrong.

By default r.sun calculates times as true solar time, whereby solar noon is 
always exactly 12 o'clock everywhere. Depending on where you are in your time 
zone, this may cause differences of up to an hour, in some cases (like Western 
Spain) even more. On top of this, the offset varies during the year according 
to the Equation of Time.

You can use the option civiltime= in r.sun to make it use 
wall clock time. For Central Europe the timezone offset is +1, +2 when 
daylight saving time is in effect.

I'm not completely sure about this, but if you use civiltime you may have to 
supply the longitude as a raster with the "longin" option. With latlon 
projection you can make a longitude raster simply with

r.mapcalc lon_raster='x()'

Hope this helps.

Thomas

On Monday 02 January 2012 12:57:27 pm Büro Seling wrote:
> Dear Group!
> 
> Happy New Year @all!
> 
> I work on a Linux GRASS 6.4.2 RC1. The area of interest is in central
> Europe and
> the projection is WGS84(EPSG:4326).
> 
> 
> When I use the r.sun module and let it show the sunset/sunrise time and
> compare
> it with the sunset/sunrise from a map created with r.sunmask I see great
> differences (up to 50 minutes).
> 
> 
> It is not the timezone (which is set correctly) in r.sunmask.
> 
> The results from r.sunmask seem to be, according to other sources, seem
> to be
> right, but the results from r.sun are fare off.
> 
> Please give a suggestions or help!
> 
> Stefan
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 

-- 
--
Thomas Huld   
Joint Research Centre of the European Commission
T.P. 450
I-21027 Ispra, Italy
phone: +39 0332785273
e-mail: thomas.h...@jrc.ec.europa.eu
--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Connecting table

2012-01-03 Thread Micha Silver

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 at 9:13 PM, Micha
  Silver 
  wrote:

   On 01/03/2012 04:50 PM, Bulent Arikan wrote:
Dear List,

  I rasterized a centroid and ran 'r.univar', whose
extended stats are saved as a text file. Then, I ran
'v.db.addtable' to create a second layer in the
attribute table of the centroid and I had columns
added in this second layer using 'v.db.addcol'. I
want GRASS to upload values from the text file but I
am not sure how to perform this task. 

  Is there a shorter way of creating a second layer
and uploading values from the text file or what
should I do next so that the columns in the second
layer will be populated using the text file I have?

  I'm not sure about a shorter way, but here's an option:
  First setup your mapset to save attributes to sqlite. 
  > v.db.connect centroid driver=sqlite database= 

  Now add the columns which will accept r.univar values to
  the sqlite table:
  > v.db.addcol centroid col="n double, null_cells
  double, cells double, min double, max double, range
  double, mean double, mean_of_abs double, stddev double,
  variance double, coeff_var double, sum double"

  Run r.univar on your raster, putting results into a text
  file
  > r.univar your_rast -g  > univar.txt

  Now do this loop to update values for the centroid:
  > 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

  Assuming you want to run this for several centroids/areas,
  you'll probably want to add a WHERE clause to the UPDATE
  statement so as to put values for only one certain row
  (centroid).

  HTH, Micha

  Thank you for your time.

GRASS 6.5 svn on Snow Leopard

-- 
BÜLENT

This mail was received via Mail-SeCure System.

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

Re: [GRASS-user] i.ortho.photo

2012-01-03 Thread Markus Neteler

On Wed, Jan 4, 2012 at 1:14 AM, Alassane Toure  wrote:
> Dear GRASS users,
> I need help on how to use "i.ortho.photo" to orhto-rectify satellite
> imagery.

Unfortunately you can only orthorectify aerial images (they have central
projection while line scanner satellite images have not...).

Sorry for no better answer (we got a new module promised by a researcher
but it hasn't been published yet to my knowledge...).

Markus

PS: Maybe interesting for orthorectificatio of aerial images:

"Robust rectification of aerial photographs in an Open Source environment"
http://dx.doi.org/10.1016/j.cageo.2011.06.002
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] i.ortho.photo

2012-01-03 Thread Alassane Toure


Dear GRASS users,
I need help on how to use "i.ortho.photo" to orhto-rectify satellite 
imagery.  I am using GRASS in linux (Ubuntu) environment and have 
already imported all necessary dataset (image to ortho, DEM and 
reference image).  After keying "i.ortho.photo" and selecting the Group, 
the following step by step process shows up but I am not able to choose 
any of the options presented.


[H[2J
i.ortho.photo --Imagery Group = orthofiles
Initialization Options:
   1. Select/Modify imagery group
   2. Select/Modify imagery group target
   3. Select/Modify target elevation model
   4. Select/Modify imagery group camera
Transformation Parameter Computations:
   5. Compute image-to-photo transformation
   6. Initialize exposure station parameters
   7. Compute ortho-rectification parameters
Ortho-rectification Option:
   8. Ortho-rectify imagery files
RETURN   exit
>

Any help is appreciated.

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

Re: [GRASS-user] Connecting table

2012-01-03 Thread Bulent Arikan

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!

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.

Thank you again,

Bulent

On Tue, Jan 3, 2012 at 9:13 PM, Micha Silver  wrote:

> **
> On 01/03/2012 04:50 PM, Bulent Arikan wrote:
>
> Dear List,
>
>  I rasterized a centroid and ran 'r.univar', whose extended stats are
> saved as a text file. Then, I ran 'v.db.addtable' to create a second layer
> in the attribute table of the centroid and I had columns added in this
> second layer using 'v.db.addcol'. I want GRASS to upload values from the
> text file but I am not sure how to perform this task.
>
>  Is there a shorter way of creating a second layer and uploading values
> from the text file or what should I do next so that the columns in the
> second layer will be populated using the text file I have?
>
>
> I'm not sure about a shorter way, but here's an option:
> First setup your mapset to save attributes to sqlite.
> > v.db.connect centroid driver=sqlite database=
>
> Now add the columns which will accept r.univar values to the sqlite table:
> > v.db.addcol centroid col="n double, null_cells double, cells double, min
> double, max double, range double, mean double, mean_of_abs double, stddev
> double, variance double, coeff_var double, sum double"
>
> Run r.univar on your raster, putting results into a text file
> > r.univar your_rast -g  > univar.txt
>
> Now do this loop to update values for the centroid:
> > 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
>
> Assuming you want to run this for several centroids/areas, you'll probably
> want to add a WHERE clause to the UPDATE statement so as to put values for
> only one certain row (centroid).
>
> HTH, Micha
>
>
>  Thank you for your time.
>
>  GRASS 6.5 svn on Snow Leopard
>
>
>  --
> BÜLENT
>
> This mail was received via Mail-SeCure System.
>
>
> ___
> grass-user mailing 
> listgrass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>
> This mail was received via Mail-SeCure System.
>
>
>
>
>
> --
> Micha Silver
> GIS Consultant, Arava Development Co.http://www.surfaces.co.il
>
>


-- 
BÜLENT ARIKAN, PhD
Senior Research Fellow
Research Center for Anatolian Civilizations
Koç University
İstiklal Caddesi No: 181 Merkez Han
Beyoğlu - ISTANBUL
TURKEY
34433
(+ 90) 212-393-6036
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Connecting table

2012-01-03 Thread Micha Silver

On 01/03/2012 04:50 PM, Bulent Arikan wrote:
Dear List,

  I rasterized a centroid and ran 'r.univar', whose extended
stats are saved as a text file. Then, I ran 'v.db.addtable' to
create a second layer in the attribute table of the centroid and
I had columns added in this second layer using 'v.db.addcol'. I
want GRASS to upload values from the text file but I am not sure
how to perform this task. 

  Is there a shorter way of creating a second layer and
uploading values from the text file or what should I do next so
that the columns in the second layer will be populated using the
text file I have?

I'm not sure about a shorter way, but here's an option:
First setup your mapset to save attributes to sqlite. 
> v.db.connect centroid driver=sqlite database= 

Now add the columns which will accept r.univar values to the sqlite
table:
> v.db.addcol centroid col="n double, null_cells double, cells
double, min double, max double, range double, mean double,
mean_of_abs double, stddev double, variance double, coeff_var
double, sum double"

Run r.univar on your raster, putting results into a text file
> r.univar your_rast -g  > univar.txt

Now do this loop to update values for the centroid:
> 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

Assuming you want to run this for several centroids/areas, you'll
probably want to add a WHERE clause to the UPDATE statement so as to
put values for only one certain row (centroid).

HTH, Micha

  Thank you for your time.

GRASS 6.5 svn on Snow Leopard

-- 
BÜLENT

  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.

-- 
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

Re: [GRASS-user] Difference in sunset/sunrise time between r.sun and r.sunmask

2012-01-03 Thread Stephen Sefick


Oh sorry, good luck.

On Mon 02 Jan 2012 10:46:44 AM EST, Büro Seling wrote:

Am 02.01.2012 16:19, schrieb Stephen Sefick:
If you use R there is a sunrise.set function in the StreamMetabolism 
package (shameless promotion). That may be helpful.


Stephen Sefick

On 01/02/2012 06:57 AM, Büro Seling wrote:

Dear Group!

Happy New Year @all!

I work on a Linux GRASS 6.4.2 RC1. The area of interest is in 
central Europe and

the projection is WGS84(EPSG:4326).


When I use the r.sun module and let it show the sunset/sunrise time 
and compare
it with the sunset/sunrise from a map created with r.sunmask I see 
great

differences (up to 50 minutes).


It is not the timezone (which is set correctly) in r.sunmask.

The results from r.sunmask seem to be, according to other sources, 
seem to be

right, but the results from r.sun are fare off.

Please give a suggestions or help!

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



Thanks for Your suggestion Stephen,
but I have to make "shadow" maps with r.sun and my problem is how to 
get r.sun work within the correct sunrise/sunset timespan.


___
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] Connecting table

2012-01-03 Thread Bulent Arikan

Dear List,

I rasterized a centroid and ran 'r.univar', whose extended stats are saved
as a text file. Then, I ran 'v.db.addtable' to create a second layer in the
attribute table of the centroid and I had columns added in this second
layer using 'v.db.addcol'. I want GRASS to upload values from the text file
but I am not sure how to perform this task.

Is there a shorter way of creating a second layer and uploading values from
the text file or what should I do next so that the columns in the second
layer will be populated using the text file I have?

Thank you for your time.

GRASS 6.5 svn on Snow Leopard


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

[GRASS-user] Extracting centroids as a raster (and are these centroids really at the center?)

2012-01-03 Thread Marcello Gorini

Dear all,

I need to extract the center of raster areas as another raster. 

Since my script is totaly raster-based (and I am not used to using vectors),
I tried to find some kind of r.thin that would generate the centroids,
instead of trying to "force" the area into lines.

I believe there is no such module (please correct me if I'm wrong), so I had
to use vectors. 

I then did:
- r.to.vect input=raster_areas output=vectorized_areas feature=area
- v.to.points in=vectorized_areas out=vector_centroids type=centroid
- v.to.rast input=vector_centroids output=raster_centroids use=val

I was succesfull, but I have to questions:
1- Is there a better way to accomplish this? 
2 - How are these centroids calculated? I ask this because they don't seem
to be the actual visual centroid, as the attached image hopefully clarifies
to you. The image shows three example areas with the centroids both as an
"x" and as a raster in pink.

I thank you all very much for any help and wish you a great new year with a
lot of intelectual challenges.

Best,
Marcello.

http://osgeo-org.1803224.n2.nabble.com/file/n7146840/areas.png 

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Extracting-centroids-as-a-raster-and-are-these-centroids-really-at-the-center-tp7146840p7146840.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] Difference in sunset/sunrise time between r.sun and r.sunmask

Re: [GRASS-user] Connecting table

Re: [GRASS-user] i.ortho.photo

[GRASS-user] i.ortho.photo

Re: [GRASS-user] Connecting table

Re: [GRASS-user] Connecting table

Re: [GRASS-user] Difference in sunset/sunrise time between r.sun and r.sunmask

[GRASS-user] Connecting table

[GRASS-user] Extracting centroids as a raster (and are these centroids really at the center?)

9 matches

Site Navigation

Mail list logo

Footer information