[GRASS-user] Importing ASCII file

Hi,
http://osgeo-org.1560.n6.nabble.com/r-in-gdal-worldclim-data-G-set-window-geographic-latitude-not-valid-for-north-td3889261.html

gdal_translate -a_ullr -180 90 180 -60 input_worldclim/hdr.adf new_boundary.tif
g.region n=90N s=60S e=180E w=180W res=00:00:30
r.in.gdal input=new_boundary.tif output=worldclim_map

Cheers
Stefano

www.spatial-ecology.net

-----Original Message-----
From: Daniel Lee [mailto:lee@isi-solutions.org]
Sent: Thursday, June 28, 2012 08:30 AM
To: ‘Rainer M Krug’
Cc: ‘Rich Shepard’, ‘GRASS user list’
Subject: Re: [GRASS-user] Importing ASCII file

Rainer,

Good idea. Here’s the output of gdalinfo:

gdalinfo prec_1.asc
Driver: AAIGrid/Arc/Info ASCII Grid
Files: prec_1.asc
Size is 43200, 18000
Coordinate System is `’
Origin = (-180.000000000000000,90.000000000000000)
Pixel Size = (0.008333333333333,-0.008333333333333)
Corner Coordinates:
Upper Left (-180.0000000, 90.0000000)
Lower Left (-180.0000000, -60.0000000)
Upper Right ( 180.0000000, 90.0000000)
Lower Right ( 180.0000000, -60.0000000)
Center ( 0.0000000, 15.0000000)
Band 1 Block=43200x1 Type=Int32, ColorInterp=Undefined
NoData Value=-9999

So it looks like Arc/Info ASCII grid is correct.

Hamish,

you’re right, editing the cell size even with vi would be painful. I wouldn’t be afraid to name names about the software, but the fact of the matter is that I don’t know what software it is. I downloaded the data from http://www.ccafs-climate.org/data/

In any case, using the -l flag did the trick! Thanks a ton, that makes my day :slight_smile: Case closed!

Best,
Daniel

Hi,

Im new to Grass GIS and I have the same problem.

I have an ascii Lidar data set with XYZ values in the following format.

ncols 1999
nrows 1998
xllcorner 459000.27618609
yllcorner 298999.76202791
cellsize 0.5
NODATA_value -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999

When I run r.in.arc I get the following error.

Illegal "yllcorner" value in header: "298999.76202791"
Illegal latitude for North
ERROR: Can't get cell header

I tried r.in.xyz and I got this error.

ERROR: Not enough data columns. Incorrect delimiter or column number? Found
the following character(s) in row 1:
[ncols 1999]

I also tried the r3.in.ascii and i got this error.

ERROR: readHeaderString: header value invalid

..........

So could you please tell me if i do something wrong?

I actually want to use the r.sun algorithm to calculate solar radiation and
if Im not mistaken the first step is to import first the ascii file to
GRASS.

Thank you

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997492.html
Sent from the Grass - Users mailing list archive at Nabble.com.

I think you should run r.in.ascii

http://grass.osgeo.org/grass63/manuals/html63_user/r.in.ascii.html

if you want to use r.sun you have to import the digital terrain model first. then you have to create a slope and an aspect rasters and then run r.sun with the r.slope.aspect command

http://grass.osgeo.org/grass63/manuals/html63_user/r.slope.aspect.html

and then finally running r.sun

El 24/08/12 03:13, sotototo escribió:

Hi,

Im new to Grass GIS and I have the same problem.

I have an ascii Lidar data set with XYZ values in the following format.

ncols 1999
nrows 1998
xllcorner 459000.27618609
yllcorner 298999.76202791
cellsize 0.5
NODATA_value -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999

When I run r.in.arc I get the following error.

Illegal "yllcorner" value in header: "298999.76202791"
Illegal latitude for North
ERROR: Can't get cell header

I tried r.in.xyz and I got this error.

ERROR: Not enough data columns. Incorrect delimiter or column number? Found
the following character(s) in row 1:
[ncols 1999]

I also tried the r3.in.ascii and i got this error.

ERROR: readHeaderString: header value invalid

..........

So could you please tell me if i do something wrong?

I actually want to use the r.sun algorithm to calculate solar radiation and
if Im not mistaken the first step is to import first the ascii file to
GRASS.

Thank you

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997492.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

--

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.pettazzi@meteogalicia.es <mailto:alberto.pettazzi@meteogalicia.es>

Hi,

I think that the real problem is about the projection system

in your raster file:
xllcorner 459000.27618609
yllcorner 298999.76202791

and the error:
Illegal latitude for North

=> grass just say that a latitue of 298999° is irrelevant :wink:

so there are 2 possibilities:
1 - your raster file use a projection and you need to import it into a new location with this projection
2 - the raster is really in decimal lat/lon, but *10000 => xllcorner = 45.9 ° and yllcorner = 29.89°

as your are using lidar data at a resolution of 0,5 it seems to me that the unit used in your ratser coordinate is meters, so you need to know the raster coordinate system before you can use it :wink:

cheers,
Sylvain

2012/8/24 Alberto Pettazzi <alberto.pettazzi@meteogalicia.es>

I think you should run r.in.ascii

http://grass.osgeo.org/grass63/manuals/html63_user/r.in.ascii.html

if you want to use r.sun you have to import the digital terrain model first. then you have to create a slope and an aspect rasters and then run r.sun with the r.slope.aspect command

http://grass.osgeo.org/grass63/manuals/html63_user/r.slope.aspect.html

and then finally running r.sun

El 24/08/12 03:13, sotototo escribió:

Hi, 

Im new to Grass GIS and I have the same problem.

I have an ascii Lidar data set with XYZ values in the following format.

ncols         1999
nrows         1998
xllcorner     459000.27618609
yllcorner     298999.76202791
cellsize      0.5
NODATA_value  -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 

When I run r.in.arc I get the following error.

Illegal "yllcorner" value in header: "298999.76202791"
Illegal latitude for North
ERROR: Can't get cell header

I tried r.in.xyz and I got this error.

ERROR: Not enough data columns. Incorrect delimiter or column number? Found
the following character(s) in row 1:
[ncols         1999]

I also tried the r3.in.ascii and i got this error.

ERROR: readHeaderString: header value invalid

..........

So could you please tell me if i do something wrong?

I actually want to use the r.sun algorithm to calculate solar radiation and
if Im not mistaken the first step is to import first the ascii file to
GRASS.

Thank you

--
View this message in context: [http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997492.html](http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997492.html)
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
[grass-user@lists.osgeo.org](mailto:grass-user@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/grass-user](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.pettazzi@meteogalicia.es


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

Hi,

The projection system that I use is British_National_Grid
Transverse_Mercator and the GCS_OSGB_1936.

I imported the projection and the I ran r.in.arc and it worked!!!!!

Thank you very much!!!!

Actually my main purpose is to run the r.sun algorithm and calculate an
annual solar radiation if possible.

The ascii file that I use is already digitized from a DSM because I want to
use certain areas(roofs) to calculate the solar radiation.

So to use r.sun for my ascii file do I have to import first the original DSM
dataset and calculate slope and aspect with r.slope.aspect and then run
r.sun importing my ascii file?

Does this makes sence at all?

Thank you very much

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997571.html
Sent from the Grass - Users mailing list archive at Nabble.com.

I tested the r.sun algorithm on my DSM and DTM dataset by importing the DSM
first and then executing the r.slope.aspect algorithm. Then I run the the
r.sun algorithm and I imported the DSM, slope and aspect and as an output I
chose only the Total global irradiance/irradiation option.

The result was a very low resolution image.(Very large pixels)

My DSM-DTM data set has a resolution of 0.5 meters though.

Does this means that r.sun has a fixed resolution or am I doing something
wrong?

Thank you in advance.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997661.html
Sent from the Grass - Users mailing list archive at Nabble.com.

I tested the r.sun algorithm on my DSM and DTM dataset by importing the DSM
first and then executing the r.slope.aspect algorithm. Then I run the the
r.sun algorithm and I imported the DSM, slope and aspect and as an output I
chose only the Total global irradiance/irradiation option.

The result was a very low resolution image.(Very large pixels)

My DSM-DTM data set has a resolution of 0.5 meters though.

Does this means that r.sun has a fixed resolution or am I doing something
wrong?

Thank you in advance.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997663.html
Sent from the Grass - Users mailing list archive at Nabble.com.

I tested the r.sun algorithm on my DSM and DTM dataset by importing the DSM
first and then executing the r.slope.aspect algorithm. Then I run the the
r.sun algorithm and I imported the DSM, slope and aspect and as an output I
chose only the Total global irradiance/irradiation option.

The result was a very low resolution image.(Very large pixels)

My DSM-DTM data set has a resolution of 0.5 meters though.

Does this means that r.sun has a fixed resolution or am I doing something
wrong?

Thank you in advance.

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997673.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hi,

The problem was that I had to run the g.region first so that I would set up
my raster resolution!!!

Then I imported my DSM, ran first r.slope.aspect to calculate slope and
aspect and then I ran the r.sun algorithm and I had my first correct
results!!

Thank you very much everybody for your valuable help!!

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997732.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hi,

Is there a way to calculate automatically the annual radiation in r.sun
because the algorithm calculates one day at a time.

Thank you

--
View this message in context: http://osgeo-org.1560.n6.nabble.com/Importing-ASCII-file-tp4984276p4997735.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On Friday 24 of August 2012 13:16:40 sotototo wrote:

Hi,

Hi!

Is there a way to calculate automatically the annual radiation in r.sun
because the algorithm calculates one day at a time.

Please, care to post mails with a clear and meaningful "subject".

All you need to do is to estimate the wanted daily values, sum'em up and, of
course, divide them by the corresponding number of days. A simple script (bash
or python) I guess would do it.

Nikos

ps- I've sent you some old (bash) scripts I've used for this (or relevant) --
hope they are useful!