Re: [GRASS-user] Precision of raster/vector float values

2012-08-24 Thread Markus Metz
On Thu, Aug 23, 2012 at 11:52 PM, Glynn Clements
gl...@gclements.plus.com wrote:

 Markus Metz wrote:

  So if I understand you correctly: 1.0e-15 is the smallest number for
  values in attribute columns although the values in a DCELL raster
  can be  smaller? A bottleneck is v.what.rast which converts
  the queried raster values into text with 15 decimal points?
  So is there any (future) way to have similar precision in a DCELL
  raster and its corresponding point vector (r.to.vect - v.what.rast)?

 The short answer is no because binary values have to be converted to
 text which for fp values is lossy.

 Note that the round-trip conversion isn't *inherently* lossy.

 It's possible to convert any binary floating-point value to decimal
 exactly.

 Arbitrary decimal values cannot be converted to (binary)
 floating-point values exactly, but decimal values which were generated
 from a floating-point value will convert back to the original value
 provided that sufficient decimal digits are used. The decimal
 representation doesn't have to be exact, only sufficiently accurate to
 be distinguishable from the adjacent floating-point values.

 Conversion to and from text is only lossy because the number of digits
 required to avoid this is excessive for any other purpose (double
 precision can represent the circumference of the earth to within 9
 nanometres; no actual measurement will be that precise).

So I misunderstood something about IEEE precision, sorry about the
confusion! Coming back to the original problem, it seems that it can
be solved for DCELL by using .15g instead of .10f, i.e. use the
same formatting rules like e.g. r.what and d.what.rast. I tested and
the values uploaded to the database are correct with .15g for DCELL.

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


Re: [GRASS-user] Precision of raster/vector float values

2012-08-24 Thread Johannes Radinger
Hi,
 So I misunderstood something about IEEE precision, sorry about the
 confusion! Coming back to the original problem, it seems that it can
 be solved for DCELL by using .15g instead of .10f, i.e. use the
 same formatting rules like e.g. r.what and d.what.rast. I tested and
 the values uploaded to the database are correct with .15g for DCELL.

 Markus M

sounds good if the origiinal problem can be solved for DCELL. If I
understand you
correctly this means that v.what.rast needs to be slighly changed?
Do I need to do it myself or will there be an update in a new revision
for 6.4.3 and/or 6.5?

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


Re: [GRASS-user] After Qgis installation - GRASS6.4 doesn't start anymore

2012-08-24 Thread Johannes Radinger
Hi,
 Please check how many files remained in /usr/lib/grass64/.
 Perhaps QGIS removed it to install again GRASS (which failed)?

Before installing QGIS (at the time when GRASS is still launching), there is no
grass64 folder in /usr/lib but there is the folder
/usr/local/grass6.4.3SVN. This seems
the location where the command grass64 is probably pointing to.
I am not sure what is the correct directory for a selfcompiled GRASS
installation
using checkinstall? And I need to build GRASS myself (different
versions, add ons,
own scripts and add-ons etc.) and the GRASS compilation itself is not
the problem.

After installing QGIS (even from the  ubuntugis-unstable ppa) the
usr/lib/grass64 is
existing. So the QGIS installation (even without the GRASS plugin)
installs a version
of GRASS64 and this installation seems to change the link of grass64
to the new installation.
So probably just the link for grass64 has to be reset again to my
real GRASS6.4?!

I tried to reinstall GRASS GIS after the QGIS installation using
make -j2  sudo checkinstall  sudo ldconfig but the problem still
remains, although
I thought that the ldconfig might solve the problem.

/Johannes


 What if you reinstall again GRASS6.4 with your
 make -j2  sudo checkinstall  sudo ldconfig
 ?

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


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread Alberto Pettazzi

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


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



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


Re: [GRASS-user] After Qgis installation - GRASS6.4 doesn't start anymore

2012-08-24 Thread Werner Macho
Hi!
Just as a suggestion ..
If you are self compiling GRASS - you should probably also self
compile QGIS .. As it seems that QGIS expects some GRASS files in
decent positions you could tell QGIS where to find the GRASS version
you would like to use and compile it ..
Maybe that solves a lot of that problems..
And I hope you don't expect QGIS to work with several versions of
GRASS at the same time (out of the box) - that would not work without
some starting scripts where you set PATHS ..

HTH
kind regards
Werner


On Fri, Aug 24, 2012 at 10:45 AM, Johannes Radinger
johannesradin...@gmail.com wrote:
 Hi,
 Please check how many files remained in /usr/lib/grass64/.
 Perhaps QGIS removed it to install again GRASS (which failed)?

 Before installing QGIS (at the time when GRASS is still launching), there is 
 no
 grass64 folder in /usr/lib but there is the folder
 /usr/local/grass6.4.3SVN. This seems
 the location where the command grass64 is probably pointing to.
 I am not sure what is the correct directory for a selfcompiled GRASS
 installation
 using checkinstall? And I need to build GRASS myself (different
 versions, add ons,
 own scripts and add-ons etc.) and the GRASS compilation itself is not
 the problem.

 After installing QGIS (even from the  ubuntugis-unstable ppa) the
 usr/lib/grass64 is
 existing. So the QGIS installation (even without the GRASS plugin)
 installs a version
 of GRASS64 and this installation seems to change the link of grass64
 to the new installation.
 So probably just the link for grass64 has to be reset again to my
 real GRASS6.4?!

 I tried to reinstall GRASS GIS after the QGIS installation using
 make -j2  sudo checkinstall  sudo ldconfig but the problem still
 remains, although
 I thought that the ldconfig might solve the problem.

 /Johannes


 What if you reinstall again GRASS6.4 with your
 make -j2  sudo checkinstall  sudo ldconfig
 ?

 guessing,
 Markus
 ___
 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] Importing ASCII file

2012-08-24 Thread Sylvain Maillard
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 ;)

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 *1 = 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 ;)

cheers,
Sylvain


2012/8/24 Alberto Pettazzi alberto.petta...@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  -
 - - - - - - - - - - - -
 - - - - - - - - - - - -
 - - - - - - - - - - -


 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 
 listgrass-user@lists.osgeo.orghttp://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 mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Bathymetric data

2012-08-24 Thread Peter Löwe
Lyle,

I'm searching for bathymetric data that can be uploaded of the bottom of the 
Atlantic Ocean that will include the seamounts. Basically at the same 
resolution that one sees with Google woud work for what I need. 

The GEBCO data is probably what you are looking for. Google uses it as well:
http://www.gebco.net/data_and_products/gridded_bathymetry_data/

Best,
Peter
-- 
Dr. Peter Löwe
peter.lo...@gmx.de





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


[GRASS-user] How to get centroid coordinates

2012-08-24 Thread Margherita Di Leo
Hi,

I have a vector of polygons and i want to create a vector of points with
the centroids of the polygons, with a connected table showing their
coordinates. Which is the simplest way to do that on G7?

Thanks

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


Re: [GRASS-user] Precision of raster/vector float values

2012-08-24 Thread Markus Metz
On Fri, Aug 24, 2012 at 10:40 AM, Johannes Radinger
johannesradin...@gmail.com wrote:
 Hi,
 So I misunderstood something about IEEE precision, sorry about the
 confusion! Coming back to the original problem, it seems that it can
 be solved for DCELL by using .15g instead of .10f, i.e. use the
 same formatting rules like e.g. r.what and d.what.rast. I tested and
 the values uploaded to the database are correct with .15g for DCELL.

 Markus M

 sounds good if the origiinal problem can be solved for DCELL. If I
 understand you
 correctly this means that v.what.rast needs to be slighly changed?
 Do I need to do it myself or will there be an update in a new revision
 for 6.4.3 and/or 6.5?

In my tests, uploading e.g. 2.5e-5 instead of 0.25 to
attribute tables works, but I am not sure if it works with all db
backends. I am also not sure if you will get the same value out after
some processing because sometimes %lf is used which prints by
default only 6 decimal places, I think. There are various binary -
text conversions happening in the db library, and they do not seem to
be consistent. That is, depending on what you are going to do with the
attributes, it may or may not work. v.what and v.db.select should
work, though. v.what.rast is now fixed in all branches, r52869-71.

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


Re: [GRASS-user] How to get centroid coordinates

2012-08-24 Thread Alexander Muriy
Hi Margherita.

I have a vector of polygons and i want to create a vector of points with
 the centroids of the polygons, with a connected table showing their
 coordinates. Which is the simplest way to do that on G7?


In GRASS 6.4.*:
-- extract centroids from polygon map
v.extract in=poly out=centr type=centroid
-- if needed convert centroids to points
v.type in=centr out=centr_pts type=centroid,point
-- add attribute table to points
v.db.addtable centr_pts col=x double,y double,z double
-- insert coords in table
v.to.db TMP_centr_pts option=coor col=x,y,z

I think in GRASS 7.0 it will be similar.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Precision of raster/vector float values

2012-08-24 Thread Markus Metz
On Fri, Aug 24, 2012 at 11:27 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 10:40 AM, Johannes Radinger
 johannesradin...@gmail.com wrote:
 Hi,
 So I misunderstood something about IEEE precision, sorry about the
 confusion! Coming back to the original problem, it seems that it can
 be solved for DCELL by using .15g instead of .10f, i.e. use the
 same formatting rules like e.g. r.what and d.what.rast. I tested and
 the values uploaded to the database are correct with .15g for DCELL.

 Markus M

 sounds good if the origiinal problem can be solved for DCELL. If I
 understand you
 correctly this means that v.what.rast needs to be slighly changed?
 Do I need to do it myself or will there be an update in a new revision
 for 6.4.3 and/or 6.5?

 In my tests, uploading e.g. 2.5e-5 instead of 0.25 to
 attribute tables works, but I am not sure if it works with all db
 backends. I am also not sure if you will get the same value out after
 some processing because sometimes %lf is used which prints by
 default only 6 decimal places, I think.

%lf is used by sscanf and correct for double. Maybe everything is fine now?

Markus M

 There are various binary -
 text conversions happening in the db library, and they do not seem to
 be consistent. That is, depending on what you are going to do with the
 attributes, it may or may not work. v.what and v.db.select should
 work, though. v.what.rast is now fixed in all branches, r52869-71.

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


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] After Qgis installation - GRASS6.4 doesn't start anymore

2012-08-24 Thread Johannes Radinger
On Fri, Aug 24, 2012 at 10:51 AM, Werner Macho werner.ma...@gmail.com wrote:
 Hi!
 Just as a suggestion ..
 If you are self compiling GRASS - you should probably also self
 compile QGIS .. As it seems that QGIS expects some GRASS files in
 decent positions you could tell QGIS where to find the GRASS version
 you would like to use and compile it ..
 Maybe that solves a lot of that problems..
 And I hope you don't expect QGIS to work with several versions of
 GRASS at the same time (out of the box) - that would not work without
 some starting scripts where you set PATHS ..


This seems one step forward, I built and installed qgis from source
and before GRASS6.4.3. After removing a package called grass-core
(which probably comes with the QGIS and causes the problems) both
GRASS and QGIS starts. During the QGIS make I set the GRASS prefix
to my original /usr/local/grass6.4.3.

Anyway I couldn't fine anything how to build/install the GRASS-QGIS plugin.
Are there any instructions? Trying to install it via apt-get fails because:
Depends: qgis (= 1.8.0-1~precise1) but 20120824-1 (self-compiled) is
to be installed.

BTW both QGIS and GRASS are installed via checkinstall. I am not
really convinced
if it really needed or if it might cause any problems (with versions
etc)? Would it get
very messy if just sudo make install is used? Any recommendations on that?

/johannes





 HTH
 kind regards
 Werner


 On Fri, Aug 24, 2012 at 10:45 AM, Johannes Radinger
 johannesradin...@gmail.com wrote:
 Hi,
 Please check how many files remained in /usr/lib/grass64/.
 Perhaps QGIS removed it to install again GRASS (which failed)?

 Before installing QGIS (at the time when GRASS is still launching), there is 
 no
 grass64 folder in /usr/lib but there is the folder
 /usr/local/grass6.4.3SVN. This seems
 the location where the command grass64 is probably pointing to.
 I am not sure what is the correct directory for a selfcompiled GRASS
 installation
 using checkinstall? And I need to build GRASS myself (different
 versions, add ons,
 own scripts and add-ons etc.) and the GRASS compilation itself is not
 the problem.

 After installing QGIS (even from the  ubuntugis-unstable ppa) the
 usr/lib/grass64 is
 existing. So the QGIS installation (even without the GRASS plugin)
 installs a version
 of GRASS64 and this installation seems to change the link of grass64
 to the new installation.
 So probably just the link for grass64 has to be reset again to my
 real GRASS6.4?!

 I tried to reinstall GRASS GIS after the QGIS installation using
 make -j2  sudo checkinstall  sudo ldconfig but the problem still
 remains, although
 I thought that the ldconfig might solve the problem.

 /Johannes


 What if you reinstall again GRASS6.4 with your
 make -j2  sudo checkinstall  sudo ldconfig
 ?

 guessing,
 Markus
 ___
 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] datum vs. sphere (grib files)

2012-08-24 Thread Margherita Di Leo
Hi,

I am currently using some grib files for meteorological data. When I set a
location referring to a georeferenced grib file, a default WGS84 is
assigned to it, because datum is unknown

datum:  ** unknown (default: WGS84) **

Actually, the grib files are referred to a sphere, so that there is an
error related to the use of WGS84. Usually the resolution of grib data is
so coarse that it doesn't really affect the information, but now I need to
estimate correctly the error in a given point. To do that, I need to define
in GRASS a location using the sphere instead of the default WGS84. How
can I do that? Is there in PROJ4 the definition of sphere, and a related
EPSG? why is it unknown?

Thanks for any hint.

Regards,

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


Re: [GRASS-user] How to get centroid coordinates

2012-08-24 Thread Margherita Di Leo
Hi Alexander,

On Fri, Aug 24, 2012 at 11:42 AM, Alexander Muriy amu...@gmail.com wrote:

 Hi Margherita.

 I have a vector of polygons and i want to create a vector of points with
 the centroids of the polygons, with a connected table showing their
 coordinates. Which is the simplest way to do that on G7?


 In GRASS 6.4.*:
 -- extract centroids from polygon map
 v.extract in=poly out=centr type=centroid
 -- if needed convert centroids to points
 v.type in=centr out=centr_pts type=centroid,point
 -- add attribute table to points
 v.db.addtable centr_pts col=x double,y double,z double
 -- insert coords in table
 v.to.db TMP_centr_pts option=coor col=x,y,z

 I think in GRASS 7.0 it will be similar.


Yes, indeed.  I used:

v.extract in=poly out=centr type=centroid
v.type in=centr out=centr_pts from_type=centroid to_type=point
v.db.addcolumn map=centr_pts col=x double precision,y double precision
v.to.db map=centr_pts option=coor col=x,y

Thanks!




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


Re: [GRASS-user] Precision of raster/vector float values

2012-08-24 Thread Johannes Radinger
On Fri, Aug 24, 2012 at 11:53 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 11:27 AM, Markus Metz
 markus.metz.gisw...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 10:40 AM, Johannes Radinger
 johannesradin...@gmail.com wrote:
 Hi,
 So I misunderstood something about IEEE precision, sorry about the
 confusion! Coming back to the original problem, it seems that it can
 be solved for DCELL by using .15g instead of .10f, i.e. use the
 same formatting rules like e.g. r.what and d.what.rast. I tested and
 the values uploaded to the database are correct with .15g for DCELL.

 Markus M

 sounds good if the origiinal problem can be solved for DCELL. If I
 understand you
 correctly this means that v.what.rast needs to be slighly changed?
 Do I need to do it myself or will there be an update in a new revision
 for 6.4.3 and/or 6.5?

 In my tests, uploading e.g. 2.5e-5 instead of 0.25 to
 attribute tables works, but I am not sure if it works with all db
 backends. I am also not sure if you will get the same value out after
 some processing because sometimes %lf is used which prints by
 default only 6 decimal places, I think.

 %lf is used by sscanf and correct for double. Maybe everything is fine now?

 Markus M

 There are various binary -
 text conversions happening in the db library, and they do not seem to
 be consistent. That is, depending on what you are going to do with the
 attributes, it may or may not work. v.what and v.db.select should
 work, though. v.what.rast is now fixed in all branches, r52869-71.

 Markus M

I also tried v.what.rast again and it seems that is works now perfectly.
Thank you for the fast responce and fixing the problem.

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


Re: [GRASS-user] How to get centroid coordinates

2012-08-24 Thread Martin Landa
Hi,

2012/8/24 Margherita Di Leo direg...@gmail.com:
 v.extract in=poly out=centr type=centroid
 v.type in=centr out=centr_pts from_type=centroid to_type=point
 v.db.addcolumn map=centr_pts col=x double precision,y double precision
 v.to.db map=centr_pts option=coor col=x,y

you could also use v.out.ascii

v.out.ascii in=poly type=centroid

Martin

-- 
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Importing ASCII file

2012-08-24 Thread sotototo
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.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user