[GRASS-user] Re: [GRASS-dev] LiDAR LAS import

2011-05-26 Thread Pierre Roudier
Hi Markus,

Just compiled again liblas svn trunk, everything is working as expected so far.

Thanks heaps for that new functionality, this is really very useful.

Pierre

2011/5/25 Markus Metz markus.metz.gisw...@googlemail.com:
 Hi all,

 GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
 (*.las or *.laz). The LAS file format is commonly used for storing
 LiDAR point clouds, but is unfortunately not supported by OGR.
 v.in.lidar uses the libLAS library [0] and is only compiled if the
 libLAS library is present.

 I chose to use the library instead of writing a custom LAS reading
 interface because the current LAS library version 1.6.1 is stable,
 supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of
 which can store LiDAR points in up to 5 different point formats. The
 user and the interface do not need to know the file version and point
 format of a given file, all that is conveniently handled by the libLAS
 library in the background. The library has Large File Support (LFS)
 and is well tested on different platforms, also with different
 endian-ness. This functionality is not that easy to replicate.

 You will need to get the libLAS library and configure GRASS 7 with
 --with-liblas in order to have the module available. Please test!

 Markus M

 [0] http://www.liblas.org
 ___
 grass-dev mailing list
 grass-...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev




-- 
Scientist
Landcare Research, New Zealand
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Installing extension from a local copy of the SVN repo

2011-05-26 Thread Hamish
Pierre wrote:
 Does anyone managed to use g.extension with a local copy of the SVN
 repository? I have problems retrieving code from the online repo using
 g.extension (see ticket #1341), but I can make a svn checkout.
 Moreover, that could come handy when a network connection is not
 available.

if you have a local checkout of the grass svn source code, and addons svn,
then there's no real need to use g.extension.

just do:

cd /usr/local/src/grass/svn/grass-addons/display/d.mon
make MODULE_TOPDIR=/usr/local/src/grass/svn/trunk/

done!


To make this easier, I set up an alias like so:
alias gmake7='make MODULE_TOPDIR=/usr/local/src/grass/svn/trunk/'

so then I just cd into the wanted addons module dir and run `gmake7`.

note you'll have to do that again after each 'make distclean' of the main
source tree as it installs into the main build dir.

If you have run 'sudo make install' for the build, add the word install
to the end of the `make` command (+sudo if needed) to install it too.

see  http://grass.osgeo.org/wiki/Compile_and_Install#Addons


Hamish

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Hamish
Hamish wrote:
[...]
  the ideal solution is to have both curvature and refection
  corrections implemented as flags in the new  improved
  r.viewshed. [...]

Benjamin wrote:
 That should be really easy to do. All that's needed is to
 amend the existing correction but taking away 1/7 to
 account for the adverse effect of refraction.

ok, done for r.viewshed in r46423. Number of visible cells
reduces slightly when the curvature flag is used, and rebounds
ever so slightly when the refraction flag is used.
Please test.


 Well, that refraction correction is really a rough
 simplification of reality. Essentially, it uses the same
 amount of correction as ArcGIS. There is some justification
 for this. You can find links to articles here:
 http://mapaspects.org/content/effects-curvature-earth-refraction-light-air-and-fuzzy-viewsheds-arcgis-92

I could not get at the Yoeli(1985) article as it's behind a
paywall my univ does not subscribe to. Can anyone say what's in
it?

 But in summary, accounting for realistic refraction conditions
 would be much more complex, as it would also have to take
 into plus different refraction at different elevations, etc.

I don't mind that / it is not so different from the physics I do
in my day job, and just using a fudge factor of +1/7th leaves me
feeling like the job is poorly done. Passing the coeff off to the
user without further guidance seems like a bit of a cop out. I
suppose there is a gradient in the coeff as you move from the
tropics to high latitudes, daily temperature, Linke factor,
humidity, aerosols, etc ... ?


 But given that most DEMs have an inherent vertical error that
 is greater than the influence of these effects,

can we quantify that? for example what's STRM 95% confidence
accuracy?

 I am not sure it's worth spending too much time on (it might
 be for very long distance visibility -- I just don't know).

it would be good for us to do a rough back of the envelope calc
to justify that before fully forgetting about it.

I guess for the worst case scenario we could try the views from
Mt. Everest and/or Olympus Mons and see what difference it makes.


thanks,
Hamish

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Markus Metz
On Thu, May 26, 2011 at 10:50 AM, Hamish hamis...@yahoo.com wrote:
 Hamish wrote:
 [...]
  the ideal solution is to have both curvature and refection
  corrections implemented as flags in the new  improved
  r.viewshed. [...]

 Benjamin wrote:
 That should be really easy to do. All that's needed is to
 amend the existing correction but taking away 1/7 to
 account for the adverse effect of refraction.

 ok, done for r.viewshed in r46423. Number of visible cells
 reduces slightly when the curvature flag is used, and rebounds
 ever so slightly when the refraction flag is used.
 Please test.


 Well, that refraction correction is really a rough
 simplification of reality. Essentially, it uses the same
 amount of correction as ArcGIS. There is some justification
 for this. You can find links to articles here:
 http://mapaspects.org/content/effects-curvature-earth-refraction-light-air-and-fuzzy-viewsheds-arcgis-92

Hm-hm. Citing from the website:
The problem is that the ratio of change due to air to curvature is
not 1:7 (0.13), as the standard refraction coefficient suggests. It is
0.325.

Last spring I put together an Excel sheet that computes this ratio.
Having the adjustable details (altitude, air pressure, wavelength,
etc.) did show me that the ratio never really changes (given earthly
conditions). What it did show me was that the ratio was always 0.325.

[...]

 But given that most DEMs have an inherent vertical error that
 is greater than the influence of these effects,

 can we quantify that? for example what's STRM 95% confidence
 accuracy?

From Farr et al. 2007:

Summary of SRTM performance. All quantities represent 90% errors in meters.

Africa  Australia   Eurasia Islands N. America  S. America
Absolute Geolocation Error  11.97.2 8.8 9   12.69
Absolute Height Error   5.6 6   6.2 8   9   6.2
Relative Height Error   9.8 4.7 8.7 6.2 7   5.5
Long Wavelength Height Error3.1 6   2.6 3.7 4   4.9

[sorry for the ugly format, it's tab separated]


 I am not sure it's worth spending too much time on (it might
 be for very long distance visibility -- I just don't know).

 it would be good for us to do a rough back of the envelope calc
 to justify that before fully forgetting about it.

 I guess for the worst case scenario we could try the views from
 Mt. Everest and/or Olympus Mons and see what difference it makes.

No need to go into mountains, just increase observer elevation offset,
preferably in a moderately flat area to get really far views. Using
correction for earth curvature only, max is a bit more than 100 km
with 3km observation offset. 200km is impossible without leaving
earth's atmosphere.

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Benjamin Ducke
 Hm-hm. Citing from the website:
 The problem is that the ratio of change due to air to curvature is
 not 1:7 (0.13), as the standard refraction coefficient suggests. It is
 0.325.

As far as I can tell, this is a mis-understanding. The value 0.325
applies to radio waves. Visible light is very close to 1:7.
You can read up on the arguments here:

http://forums.esri.com/Thread.asp?c=3f=40t=161962#474778

There is also some more information in that forum thread
regarding more realistic modelling of refraction under
different atmospheric conditions.

I realize the whole discourse is somewhat clouded. But I don't
have access to most of the relevant literature for the time
being, nor do I have the necessary scientific background 
-- so any fresh input will be much appreciated!

Btw.: using r.ecurv.comp, one can freely specify the
atmospheric correction factor.

 [...]
 
  But given that most DEMs have an inherent vertical error that
  is greater than the influence of these effects,
 
  can we quantify that? for example what's STRM 95% confidence
  accuracy?
 
 From Farr et al. 2007:
 
 Summary of SRTM performance. All quantities represent 90% errors in
 meters.
 
 Africa Australia Eurasia Islands N. America S. America
 Absolute Geolocation Error 11.9 7.2 8.8 9 12.6 9
 Absolute Height Error 5.6 6 6.2 8 9 6.2
 Relative Height Error 9.8 4.7 8.7 6.2 7 5.5
 Long Wavelength Height Error 3.1 6 2.6 3.7 4 4.9
 
 [sorry for the ugly format, it's tab separated]

What I wold love to see is a method for probabilistic
viewsheds, which adds random +/- offsets (within the
vertical error range) to the elevation model cells,
runs the viewshed computations several times, each time
with new random offsets, then outputs the average visibility
of each cell after n runs (not sure how best to determine
n). That would be much more realistic than those over-
confident 0/1 viewsheds.

Such a method could even take into account roughly modelled
blocks of vegetation or other obstacles for which height
is hard to quantify precisely.

-- shouldn't be too hard to implement in a little script.

Ben

 
 
  I am not sure it's worth spending too much time on (it might
  be for very long distance visibility -- I just don't know).
 
  it would be good for us to do a rough back of the envelope calc
  to justify that before fully forgetting about it.
 
  I guess for the worst case scenario we could try the views from
  Mt. Everest and/or Olympus Mons and see what difference it makes.
 
 No need to go into mountains, just increase observer elevation offset,
 preferably in a moderately flat area to get really far views. Using
 correction for earth curvature only, max is a bit more than 100 km
 with 3km observation offset. 200km is impossible without leaving
 earth's atmosphere.
 
 Markus M


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Benjamin Ducke
- Original Message -
 Hamish wrote:

[..]
 
 ok, done for r.viewshed in r46423. Number of visible cells
 reduces slightly when the curvature flag is used, and rebounds
 ever so slightly when the refraction flag is used.
 Please test.
 

Cool, that's what one would expect. Reassuring.

 
  Well, that refraction correction is really a rough
  simplification of reality. Essentially, it uses the same
  amount of correction as ArcGIS. There is some justification
  for this. You can find links to articles here:
  http://mapaspects.org/content/effects-curvature-earth-refraction-light-air-and-fuzzy-viewsheds-arcgis-92
 
 I could not get at the Yoeli(1985) article as it's behind a
 paywall my univ does not subscribe to. Can anyone say what's in
 it?
 
  But in summary, accounting for realistic refraction conditions
  would be much more complex, as it would also have to take
  into plus different refraction at different elevations, etc.
 
 I don't mind that / it is not so different from the physics I do
 in my day job, and just using a fudge factor of +1/7th leaves me
 feeling like the job is poorly done. Passing the coeff off to the
 user without further guidance seems like a bit of a cop out. I
 suppose there is a gradient in the coeff as you move from the
 tropics to high latitudes, daily temperature, Linke factor,
 humidity, aerosols, etc ... ?

I am sure there is. But I lack the background to judge this
correctly.
 
  But given that most DEMs have an inherent vertical error that
  is greater than the influence of these effects,
 
 can we quantify that? for example what's STRM 95% confidence
 accuracy?
 

[I think this needs a probabilistic approach, see my other
reply to this thread.]

  I am not sure it's worth spending too much time on (it might
  be for very long distance visibility -- I just don't know).
 
 it would be good for us to do a rough back of the envelope calc
 to justify that before fully forgetting about it.
 
 I guess for the worst case scenario we could try the views from
 Mt. Everest and/or Olympus Mons and see what difference it makes.

-- that would rock :)

Ben

 
 
 thanks,
 Hamish


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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


[GRASS-user] increase performance of i.ortho.photo/i.photo.rectify

2011-05-26 Thread Andras Balazs

Hi,

I am orthorectifying 3 channel aerial photographs using i.ortho.photo 
(GRASS 6.4.1, Ubuntu 10.04 64bit, dual core (each 3 GHz), 4 GB RAM).
I'm new to GRASS so no clue whether it's possible to make the 
rectification process to use the computer's resources  better. 
i.photo.rectify is using at most 30% CPU, processing of one channel 
takes about 15-20 minutes. I suppose it would be much faster if it would 
use one core running at 100%.
Is there an optimal amount of memory that should be assigned to the 
process or the more the better?


Any  suggestions would be more than welcome!

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Benjamin Ducke
- Original Message -
 On Thu, May 26, 2011 at 12:26 PM, Benjamin Ducke
 benjamin.du...@oxfordarch.co.uk wrote:
  Hm-hm. Citing from the website:
  The problem is that the ratio of change due to air to curvature is
  not 1:7 (0.13), as the standard refraction coefficient suggests. It
  is 0.325.
 
  As far as I can tell, this is a mis-understanding. The value 0.325
  applies to radio waves. Visible light is very close to 1:7.
 
 What if I am interested in radio waves, not visible light, e.g. for
 antenna relay positions? IMHO, that refraction coefficient should not
 be hard-coded.
 

Agreed. It's a settable value in r.ecurv.comp and should also be one
in all GRASS modules that have refraction compensation.

Ben

 
  I realize the whole discourse is somewhat clouded. But I don't
  have access to most of the relevant literature for the time
  being, nor do I have the necessary scientific background
 
 Me neither. But any correction should take into account that the
 observer is not necessarily a human without optical equipment
 (telescope etc), but can also be some technical device, e.g. a sender
 or receiver of whatever signals.
 
 my .2c
 
 Markus M
 


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

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


Re: [GRASS-user] GRASS earth curvature correction (viewsheds, LOS)

2011-05-26 Thread Hamish
   As far as I can tell, this is a mis-understanding. The
   value 0.325 applies to radio waves. Visible light is
   very close to 1:7.
  
  What if I am interested in radio waves, not visible light,
  e.g. for antenna relay positions? IMHO, that refraction
  coefficient should not be hard-coded.
 
 Agreed. It's a settable value in r.ecurv.comp and should
 also be one in all GRASS modules that have refraction
 compensation.

ok good point, wavelength matters  VHF LOS propagation distance
is an important problem to model. r.viewshed now has a user
settable refection coefficient in the range 0.0-1.0.
coeff=0.0 is like no refraction, 1.0 totally cancels out
any curvature of the Earth.

btw 1/7 is not 0.13, it's ~0.143. (to be picky)


Hamish

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


[GRASS-user] problem installing addons in grass7

2011-05-26 Thread Agustin Diez Castillo
Dear list,
I gues this is basic stuff but I can't find a solution to install install.
When I try to install some addons in grass7, it advise me to install 'install' 
first. 
g.extension -l svnurl=https://svn.osgeo.org/grass/grass-addons/grass7 
prefix=$GRASS_ADDON_PATH
ERROR: install required. Please install 'install' first.
Is that related to $GRASS_ADDON_PATH ?
I'm on mac intel.
Thanks___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] (sans objet)

2011-05-26 Thread LUCKHAUPT DANIEL
Bonsoir
votre site ne m'interrsse plus, jesuis en France et je ne parle pas anglais.
Je vous prierais de ne plus m'adresser vos messages

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


Re: [GRASS-user] (sans objet)

2011-05-26 Thread MORREALE Jean Roc

this is about unsubscribing...

Utilisez le lien suivant, saisissez votre email dans la case 
unsubscribe en bas de la page.


Le 26/05/2011 21:36, LUCKHAUPT DANIEL a écrit :

Bonsoir
votre site ne m'interrsse plus, jesuis en France et je ne parle pas anglais.
Je vous prierais de ne plus m'adresser vos messages

Amicalement




___
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] (sans objet)

2011-05-26 Thread Vincent Bain
Daniel,

--in french, sorry for the exception --

pour résilier votre abonnement à cette liste, il faut vous rendre à la
page suivante :

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

La dernière rubrique (unsubscribe) vous permet de vous désinscrire. Vous
pouvez visualiser la page en français en sélectionnant la langue dans la
liste déroulante en haut à droite.

Cordialement,
VB

Le jeudi 26 mai 2011 à 20:36 +0100, LUCKHAUPT DANIEL a écrit :
 Bonsoir
 votre site ne m'interrsse plus, jesuis en France et je ne parle pas
 anglais.
 Je vous prierais de ne plus m'adresser vos messages
 
 Amicalement
 
 ___
 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] Introduction and installing GRASS

2011-05-26 Thread David Colyer
Hello GRASS users

As I’m new to GRASS and new to this list, allow me to introduce myself.
I’m a part-time GIS post-grad student in Aotearoa / New Zealand. 

GRASS doesn’t seem to be widely used in this country. If there’s anyone
from NZ on this list I’d love to hear from them. University courses are
based around ARC, although some opensource programmes were used in my
last course.

One of my main interests in GIS is exploring the potential of GIS for
community groups, NGOs and activist groups. This inevitably leads using
open source software like GRASS.

I’m planning to blog about my experiences, first installing and learning
to use GRASS and other opensource and free to use software, and then
exploring how these might be useful for community groups. I hope that
this record of my experiences might be useful to others starting out
using opensource GIS. 

I’d also be happy to contribute to the GDP - GRASS Documentation
Project. My own experiences as someone completely new to GRASS could
feed in to the tutorial and help pages. And I could also help with
“reading existing doc in order to weed out completely outdated stuff”.

But first I need to install GRASS on my laptop. And that’s where I’ve
encountered my first problem! I hope someone on this list can help.

I’m using a Presario CQ64, which has an Athlon 64 processor (which could
be part of the problem). The current OS is Ubuntu 10.10 Maverick
Meerkat.

I’ve followed the instructions on the Ubuntugis page. According to the
Ubuntu Software Centre, GRASS is installed, and files are indeed present
on my HD. I just can’t find a way to open the programme!

[I should say that I’m also very new to Linux.] I expected there to be a
GRASS icon that I click to open it, but can’t find anything like that.
Do I have to use command line? Or has something gone wrong?

Any help appreciated.


Cheers

David

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


Re: [GRASS-user] Introduction and installing GRASS

2011-05-26 Thread Daniel Victoria
welcome david,

What do you mean you can't open the program? You can't run it? Or you
can run but you are having trouble setting up the location and mapset?

Anyway, I'm not sure Ubuntu Gis will put a item on your menu so what
happens if you open a terminal and type grass
Do you see anything?

cheers
Daniel

On Thu, May 26, 2011 at 9:20 PM, David Colyer col...@pl.net wrote:
 Hello GRASS users

 As I’m new to GRASS and new to this list, allow me to introduce myself. I’m
 a part-time GIS post-grad student in Aotearoa / New Zealand.

 GRASS doesn’t seem to be widely used in this country. If there’s anyone from
 NZ on this list I’d love to hear from them. University courses are based
 around ARC, although some opensource programmes were used in my last course.

 One of my main interests in GIS is exploring the potential of GIS for
 community groups, NGOs and activist groups. This inevitably leads using open
 source software like GRASS.

 I’m planning to blog about my experiences, first installing and learning to
 use GRASS and other opensource and free to use software, and then exploring
 how these might be useful for community groups. I hope that this record of
 my experiences might be useful to others starting out using opensource GIS.

 I’d also be happy to contribute to the GDP - GRASS Documentation Project. My
 own experiences as someone completely new to GRASS could feed in to the
 tutorial and help pages. And I could also help with “reading existing doc in
 order to weed out completely outdated stuff”.

 But first I need to install GRASS on my laptop. And that’s where I’ve
 encountered my first problem! I hope someone on this list can help.

 I’m using a Presario CQ64, which has an Athlon 64 processor (which could be
 part of the problem). The current OS is Ubuntu 10.10 Maverick Meerkat.

 I’ve followed the instructions on the Ubuntugis page. According to the
 Ubuntu Software Centre, GRASS is installed, and files are indeed present on
 my HD. I just can’t find a way to open the programme!

 [I should say that I’m also very new to Linux.] I expected there to be a
 GRASS icon that I click to open it, but can’t find anything like that. Do I
 have to use command line? Or has something gone wrong?

 Any help appreciated.


 Cheers

 David


 ___
 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: i.atcorr returns all NULL values

2011-05-26 Thread Chemin, Yann (IWMI)
Hi Juan,

 

Can you please give the download link for your images,

Could you also check the output of i.landsat.toar for them and tell if
reflectance ranges are valid/logic.

 

Thank you,

Yann

 

From: Juan Benavides Duque [mailto:jbena...@siu.edu] 
Sent: Thursday, May 26, 2011 11:38 PM
To: Chemin, Yann (IWMI)
Cc: Markus Metz; Elena Mezzini
Subject: Re: [GRASS-user] Re: i.atcorr returns all NULL values

 


I tried Yann's code for the i.atcorr on some Landsat TM5 images

It worked very nice for images taken after 1995 but before that still
returns null values when running i.atcorr for bands 1 and 2 

I used TM5 scenes from the same location for 1986, 1989, and 1996 and
the first two (1986 and 1989) had the same problem with the null
values... 

sorry I can provide a way to fix it but  I hope somebody will

juan c 






On Tue, May 24, 2011 at 3:49 AM, Chemin, Yann (IWMI)
y.che...@cgiar.org wrote:

Each created visibility map holds only one value r.mapcalc
expression=visibility=${vis_list[$i]} --overwrite so why not just use
this visibility value as input in the parameter file instead of
creating a map where all cells have the same value?

Yes, this is a valid point, the script is designed to (hopefully soon)
encompass raster maps of visibility data (maybe interpolated...), so
this is a placeholder for the next steps.


-Original Message-
From: Markus Metz [mailto:markus.metz.gisw...@googlemail.com]
Sent: Tuesday, May 24, 2011 12:52 PM
To: Chemin, Yann (IWMI)
Cc: grass-user@lists.osgeo.org; Elena Mezzini; Markus Neteler

Subject: Re: [GRASS-user] Re: i.atcorr returns all NULL values

On Mon, May 23, 2011 at 9:36 PM, Markus Neteler nete...@osgeo.org
wrote:
 Hi Yann,

 On Mon, May 23, 2011 at 5:07 AM, Chemin, Yann (IWMI)
y.che...@cgiar.org wrote:
 p192 r030 image of July 2003 of Italy (L5TM) successfully corrected
 for band 1 and 2.
 The following script works well in GRASS GIS Trunk SVN.

 (better send as attachment since a series of line breaks got broken)

 ...
 # For i.atcorr scripting
 #-
 vis_list=(10 10 8 9.7 15 8 7 10 10 9.7 12 9.7 7 12 12 12 3 15 12 9.7
 6 15) vis_len=${#vis_list[*]} echo $vis_len

 ... this is not clear to me: why so many values and where do they
 originate from? Since we have only 6 channels to work with...

Moreover, how can it be possible that visibility is different for
different channels of the same scene? From the documentation it seems
that visibility is related to aerosol concentration at 550nm which can
not possibility be different for different bands of the same scene.
Each created visibility map holds only one value r.mapcalc
expression=visibility=${vis_list[$i]} --overwrite so why not just use
this visibility value as input in the parameter file instead of creating
a map where all cells have the same value?

Markus M
___
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] Introduction and installing GRASS

2011-05-26 Thread Pierre Roudier
Kia ora David,

Fire up a terminal, and type grass, then enter. This is launching
Grass, and a GUI will show up. You will then have to specify a path to
store your GRASS data, and define a location (ie a coordinate system +
a geographic extent) for your first project.

One of the great feature of GRASS is to be usable from the terminal
and from its graphical interface.

Welcome aboard,

Pierre (from Palmerston North, NZ)

2011/5/27 David Colyer col...@pl.net:
 Hello GRASS users

 As I’m new to GRASS and new to this list, allow me to introduce myself. I’m
 a part-time GIS post-grad student in Aotearoa / New Zealand.

 GRASS doesn’t seem to be widely used in this country. If there’s anyone from
 NZ on this list I’d love to hear from them. University courses are based
 around ARC, although some opensource programmes were used in my last course.

 One of my main interests in GIS is exploring the potential of GIS for
 community groups, NGOs and activist groups. This inevitably leads using open
 source software like GRASS.

 I’m planning to blog about my experiences, first installing and learning to
 use GRASS and other opensource and free to use software, and then exploring
 how these might be useful for community groups. I hope that this record of
 my experiences might be useful to others starting out using opensource GIS.

 I’d also be happy to contribute to the GDP - GRASS Documentation Project. My
 own experiences as someone completely new to GRASS could feed in to the
 tutorial and help pages. And I could also help with “reading existing doc in
 order to weed out completely outdated stuff”.

 But first I need to install GRASS on my laptop. And that’s where I’ve
 encountered my first problem! I hope someone on this list can help.

 I’m using a Presario CQ64, which has an Athlon 64 processor (which could be
 part of the problem). The current OS is Ubuntu 10.10 Maverick Meerkat.

 I’ve followed the instructions on the Ubuntugis page. According to the
 Ubuntu Software Centre, GRASS is installed, and files are indeed present on
 my HD. I just can’t find a way to open the programme!

 [I should say that I’m also very new to Linux.] I expected there to be a
 GRASS icon that I click to open it, but can’t find anything like that. Do I
 have to use command line? Or has something gone wrong?

 Any help appreciated.


 Cheers

 David


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





-- 
Scientist
Landcare Research, New Zealand
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user