Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Nikos Alexandris]

Martin:

> >> 2015-05-05 13:42 GMT+02:00 Nikos Alexandris :
> >> >> it's not possible, to enable installing this extension via
> >> >> g.extension, you need to move this extension to `grass7/imagery`.

Nikos:

> >> > Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
> >> > to confirm.

Markus:

> In which sense "safest place"? The directory
> grass-addons/grass7/imagery/

To test, before moving something into something more "official". That's
all. I haven't used svn that much, now or in the past, so I don't have a
clear overview for many of its functions. As well, it doesn't feel so easy as 
git.


> is the right place for imagery Addons.

thanks, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading null row 8 for

[Maris Nartiss]

And just to be sure - OS and Python version.

I was observing some strange error on Windows some time a go while
running similar simple loop script. As on Linux it was fine, I wasn't
investigating it any further.


Maris.

2015-05-05 23:49 GMT+03:00 Luca Delucchi :
> On 5 May 2015 at 13:49, Alba German  wrote:
>> http://pastebin.com/rMgRsqDp
>>
>
> could you send the output of "r.info puntosmonitoreo"
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading null row 8 for

[Luca Delucchi]

On 5 May 2015 at 13:49, Alba German  wrote:
> http://pastebin.com/rMgRsqDp
>

could you send the output of "r.info puntosmonitoreo"

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading null row 8 for

[Markus Neteler]

On Tue, May 5, 2015 at 1:49 PM, Alba German  wrote:
> http://pastebin.com/rMgRsqDp

I don't see any obvious mistake in your Python script. Perhaps a North
Carolina based use case may help us to find the issue.

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

Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem

[joanna mardas]

Hello! It's me again :)
> If you go all the way from DN to Top-of-Atmosphere reflectances (via
> i.landsat.toar), then to Top-of-Canopy (via i.atcorr), you'll have
> floating point values ranging in [0, 1.0].  If you recode this back to
> 8-bit,
> you should consider whether there is an important loss of the
> radiometric resolution.
>
> So, recoding to another range is different than converting to integer
> numbers and trying to preserve the range.
 
The thing that worries me is that I don't know how to check if the loss of the radiometric resolution is important :/ What should I compare? 
I was trying to convert to integer through r.mapcalc (the only other way I've found) with the function int(x) and x was my map (I hope it was ok to put map instead of x) but the result was a map with "one shade" of grey, so maybe it was wrong to put a map instead of x... 
 
According to i.atcorr there is an option "output raster map as integer" (i), so if my input file will be _toar2@konfa (float) and I check that option I will have a map with integer values, right?
However, the most confusing thing for me with i.atcorr is "the aerosol optical depth". I don't have "meteorological parameter visibility". I have images from 1984 and 2007. I've found files for Global Aerosol Climatology (1981-2006) on this website http://gacp.giss.nasa.gov/data_sets/ I've found the proper row and column in the asci format, but they don't have data for 
2007. I was trying to find it on different pages http://modis-atmos.gsfc.nasa.gov/MOD04_L2/acquiring.html but areas of my interest are black - so no data. On your page github with i.landsat.toar and i.atcorr you wrote "the value for aerosols optical depth (AOD), is set to 0.111 for winter and 0.222 for summer aquisitions" Are these default values? For DOS methods?
Can I use i.landsat.toar with DOS3  instead of i.atcorr? The others where using this http://gis.stackexchange.com/questions/126742/which-dos-method-use-to-convert-at-sensor-radiance-to-at-surface-values-in-grass And also on your graph (the one on github) Nikos, this DOS method leads to "corrected" reflectance. So it means that I can omit i.atccor, right? I'm thinking about preprocessing of my images like this: i.landsat.toar + DOS3, 
 then r.recode (I don't know the other way to change float to integer), then i.histo.match And after that classification (I want to compare land change cover, it is Syrian Jezirah, so +/-95% is agriculture).
Greetings
Joanna
 


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

Re: [GRASS-dev] g.remove usage syntax

[Moritz Lennert]

On 05/05/15 15:41, Margherita Di Leo wrote:

Hi Moritz,

On Tue, May 5, 2015 at 2:27 PM, Moritz Lennert
mailto:mlenn...@club.worldonline.be>> wrote:

On 05/05/15 12:28, Margherita Di Leo wrote:

Dear All,

I find the current syntax of g.remove a bit cumbersome, because it
doesn't seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:

g.remove vect name=foo -f

Without the "name=" it won't work, which is not in line to the
usage of
other commands.
To me it would be more natural (and indeed i always type wrong
the first
time) something like:

g.remove vect name foo -f

being name one of the two options (name, pat) that could be
identifier=
or something better. In this case, it would be possible to type the
former command or the extended form:

g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name="f*" -f
(g.remove vect pat "f*" -f)

what do you think?


AFAIK, this would mean a fundamental change in the way the parser works.


hmm.. I don't understand why. I tried to tailor this proposal on the
current behavior of the parser, as far as I could understand it. Can you
explain a bit more?


AFAIK, the parser only accepts the first argument as positional 
argument, for all the other arguments you have to provide the parameter 
name, so in your proposal


g.remove vect id=name searchstring=foo

would work, but

g.remove vect name foo

wouldn't.

As a side question: why do you find

g.remove type=vect id=pattern name="f*"

easier

than the current

g.remove type=vect pattern="f*"

?

The current behaviour does mean less typing (and just as much compared 
to your proposal with positional parameters, except for the '=').


Moritz


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

Re: [GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

Hi Moritz,

On Tue, May 5, 2015 at 2:27 PM, Moritz Lennert  wrote:

> On 05/05/15 12:28, Margherita Di Leo wrote:
>
>> Dear All,
>>
>> I find the current syntax of g.remove a bit cumbersome, because it
>> doesn't seem to me in line with what happens with other commands.
>> If I want to remove the vector file foo, I have to type:
>>
>> g.remove vect name=foo -f
>>
>> Without the "name=" it won't work, which is not in line to the usage of
>> other commands.
>> To me it would be more natural (and indeed i always type wrong the first
>> time) something like:
>>
>> g.remove vect name foo -f
>>
>> being name one of the two options (name, pat) that could be identifier=
>> or something better. In this case, it would be possible to type the
>> former command or the extended form:
>>
>> g.remove type=vect identifier=name name=foo -f
>> or
>> g.remove type=vect identifier=pattern name="f*" -f
>> (g.remove vect pat "f*" -f)
>>
>> what do you think?
>>
>
> AFAIK, this would mean a fundamental change in the way the parser works.
>

hmm.. I don't understand why. I tried to tailor this proposal on the
current behavior of the parser, as far as I could understand it. Can you
explain a bit more?

>
> I think it might be better to create small wrapper scripts, e.g.:
>
> g.remove.vect
>
> which could use just the name option of g.remove to have a syntax such as
> this:
>
> g.remove.vect foo -f
>
> If you use GNU/Linux you can also do this very simply by defining a
> function in .grass7/bashrc:
>
> g.remove.vect ()
> {
> g.remove type=vect name=$@
> }
>

Thanks for the idea, I'll try .



-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] g.remove usage syntax

[Markus Neteler]

On Tue, May 5, 2015 at 2:46 PM, Martin Landa  wrote:
> 2015-05-05 14:28 GMT+02:00 Margherita Di Leo :
>
>> Sure. Is there any place (track? wiki?) already where to collect and discuss
>> ideas? I saw recently in ML another post about r.shaded.relief, I haven't
>> followed up but perhaps also that discussion could be included.
>
> why not ticket with milestone 'GRASS 8'? Martin

yes and additionally
http://trac.osgeo.org/grass/wiki/Grass8Planning

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

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Vaclav Petras]

On Tue, May 5, 2015 at 8:41 AM, Nikos Alexandris 
wrote:
>
> * Martin Landa  [2015-05-05 13:41:32 +0200]:
>
> > 2015-05-05 13:42 GMT+02:00 Nikos Alexandris :
> > >> it's not possible, to enable installing this extension via
> > >> g.extension, you need to move this extension to `grass7/imagery`.
> > >
> > > Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
> > > to confirm.
> >
> > yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job.
Martin
>
> Noted, thank you for your time.

You need to `svn checkout` the whole repository for this operation. At
least this is what I have (grass-addons for work in addons but also the
whole repo for these moves).

> Nikos
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Markus Neteler]

On Tue, May 5, 2015 at 2:41 PM, Nikos Alexandris
 wrote:
> * Martin Landa  [2015-05-05 13:41:32 +0200]:
>
>> 2015-05-05 13:42 GMT+02:00 Nikos Alexandris :
>> >> it's not possible, to enable installing this extension via
>> >> g.extension, you need to move this extension to `grass7/imagery`.
>> >
>> > Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
>> > to confirm.

In which sense "safest place"? The directory
grass-addons/grass7/imagery/

is the right place for imagery Addons.

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

Re: [GRASS-dev] g.remove usage syntax

[Martin Landa]

2015-05-05 14:28 GMT+02:00 Margherita Di Leo :

> Sure. Is there any place (track? wiki?) already where to collect and discuss
> ideas? I saw recently in ML another post about r.shaded.relief, I haven't
> followed up but perhaps also that discussion could be included.

why not ticket with milestone 'GRASS 8'? Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Nikos Alexandris]

* Martin Landa  [2015-05-05 13:41:32 +0200]:

> 2015-05-05 13:42 GMT+02:00 Nikos Alexandris :
> >> it's not possible, to enable installing this extension via
> >> g.extension, you need to move this extension to `grass7/imagery`.
> >
> > Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
> > to confirm.
> 
> yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job. Martin

Noted, thank you for your time.

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

Re: [GRASS-dev] g.remove usage syntax

[Moritz Lennert]

On 05/05/15 12:28, Margherita Di Leo wrote:

Dear All,

I find the current syntax of g.remove a bit cumbersome, because it
doesn't seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:

g.remove vect name=foo -f

Without the "name=" it won't work, which is not in line to the usage of
other commands.
To me it would be more natural (and indeed i always type wrong the first
time) something like:

g.remove vect name foo -f

being name one of the two options (name, pat) that could be identifier=
or something better. In this case, it would be possible to type the
former command or the extended form:

g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name="f*" -f
(g.remove vect pat "f*" -f)

what do you think?


AFAIK, this would mean a fundamental change in the way the parser works.

I think it might be better to create small wrapper scripts, e.g.:

g.remove.vect

which could use just the name option of g.remove to have a syntax such 
as this:


g.remove.vect foo -f

If you use GNU/Linux you can also do this very simply by defining a 
function in .grass7/bashrc:


g.remove.vect ()
{
g.remove type=vect name=$@
}


Moritz

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

Re: [GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

On Tue, May 5, 2015 at 3:30 AM, Martin Landa  wrote:

> Hi,
>
> 2015-05-05 12:28 GMT+02:00 Margherita Di Leo :
>
> > being name one of the two options (name, pat) that could be identifier=
> or
> > something better. In this case, it would be possible to type the former
> > command or the extended form:
> >
> > g.remove type=vect identifier=name name=foo -f
> > or
> > g.remove type=vect identifier=pattern name="f*" -f
> > (g.remove vect pat "f*" -f)
> >
> > what do you think?
>
> no idea, in any case it's issue for GRASS 8. Martin
>

Sure. Is there any place (track? wiki?) already where to collect and
discuss ideas? I saw recently in ML another post about r.shaded.relief, I
haven't followed up but perhaps also that discussion could be included.

Thanks

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading null row 8 for

[Alba German]

http://pastebin.com/rMgRsqDp

2015-05-04 15:36 GMT-03:00 Markus Neteler :

> On Mon, May 4, 2015 at 8:05 PM, Alba German  wrote:
> > Hello!
> > I am running a loop with several r.mapcalc. I am using GRASS 7.1. The
> > function stops with an error:
> >
> > ERROR: Error reading null row 8 for 
> >
> > I've noticed that Paulo van Breugel, had the same error but I didn't see
> the
> > solution to it. Obviously it has something to do with the raster called
> > MASK, created with r.mask before running the loop of multiple r.mapcalc.
> > The code itself has no problem and is very simple and works just fine
> with
> > the same list of images, but without running r.mask first.
>
> Hi Alba,
>
> could you post that part of the code e.g. here
> http://pastebin.com/
>
> ? It sounds like a race condition...
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Martin Landa]

2015-05-05 13:42 GMT+02:00 Nikos Alexandris :
>> it's not possible, to enable installing this extension via
>> g.extension, you need to move this extension to `grass7/imagery`.
>
> Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
> to confirm.

yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Nikos Alexandris]

Nikos Alexandris:

> > I am trying to not mess-up anything in grass-addons.  Hence, I first
> > uploaded the i.fusion.hpf script in sandbox:
> > .

> > Is it possible to get the add-on from the sandox, via g.extension, under
> > Windows?  I have no easy access to a windows machine with GRASS and co.

Martin:

> it's not possible, to enable installing this extension via
> g.extension, you need to move this extension to `grass7/imagery`.

Thanks Martin.  Is grass7/imagery the safest place to move into?  Just
to confirm.

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

Re: [GRASS-dev] g.remove usage syntax

[Martin Landa]

Hi,

2015-05-05 12:28 GMT+02:00 Margherita Di Leo :

> being name one of the two options (name, pat) that could be identifier= or
> something better. In this case, it would be possible to type the former
> command or the extended form:
>
> g.remove type=vect identifier=name name=foo -f
> or
> g.remove type=vect identifier=pattern name="f*" -f
> (g.remove vect pat "f*" -f)
>
> what do you think?

no idea, in any case it's issue for GRASS 8. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g.remove usage syntax

[Margherita Di Leo]

Dear All,

I find the current syntax of g.remove a bit cumbersome, because it doesn't
seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:

g.remove vect name=foo -f

Without the "name=" it won't work, which is not in line to the usage of
other commands.
To me it would be more natural (and indeed i always type wrong the first
time) something like:

g.remove vect name foo -f

being name one of the two options (name, pat) that could be identifier= or
something better. In this case, it would be possible to type the former
command or the extended form:

g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name="f*" -f
(g.remove vect pat "f*" -f)

what do you think?

Thank you

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2668: "Browse" button v.external

[GRASS GIS]

#2668: "Browse" button v.external
-+-
 Reporter:  madi |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.1
Component:  Default  |Version:  unspecified
 Keywords:  v.external   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It would be useful to have the "browse" button in the GUI of v.external,
 just like the one available for r.external, in the field of "Name of input
 OGR or PostGIS data source" (input parameter).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Martin Landa]

Hi,

2015-05-05 11:54 GMT+02:00 Nikos Alexandris :
> I am trying to not mess-up anything in grass-addons.  Hence, I first
> uploaded the i.fusion.hpf script in sandbox:
> .
>
> Is it possible to get the add-on from the sandox, via g.extension, under
> Windows?  I have no easy access to a windows machine with GRASS and co.

it's not possible, to enable installing this extension via
g.extension, you need to move this extension to `grass7/imagery`.
Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Testing an add-on from sandbox before moving to grass-addons

[Nikos Alexandris]

Hi,

I am trying to not mess-up anything in grass-addons.  Hence, I first
uploaded the i.fusion.hpf script in sandbox:
.

Is it possible to get the add-on from the sandox, via g.extension, under
Windows?  I have no easy access to a windows machine with GRASS and co.

Anyone willing to test?

Thanks, Nikos


ps- the plan is, still, to integrate the method in i.pansharpen, but I really
have no time to work on this also.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gdal/ogr 2.0 beta 1 available - grass gis ready?

[Martin Landa]

Hi,

2015-05-04 23:16 GMT+02:00 Helmut Kudrnovsky :
> http://lists.osgeo.org/pipermail/gdal-dev/2015-May/041694.html
>
> is grass gis already ready for the next generation gdal/ogr?

I am using GRASS 7 together with GDAL 2.0 for several months, recently
I added also support for multigeometry support [1].

Martin

[1] http://freegis.fsv.cvut.cz/wiki/images/2/26/Grass70-vfr.png

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem

[Nikos Alexandris]

* joanna mardas  [2015-05-05 00:19:02 +0200]:

>Hello!
> 
>You both are my heros! Thank you Moritz and Nikos!
> 
>r.recode worked :D I did i.histo.match on two test images and it looks
>fine.

If you go all the way from DN to Top-of-Atmosphere reflectances (via
i.landsat.toar), then to Top-of-Canopy (via i.atcorr), you'll have
floating point values ranging in [0, 1.0].  If you recode this back to 8-bit,
you should consider whether there is an important loss of the radiometric 
resolution.

So, recoding to another range is different than converting to integer
numbers and trying to preserve the range. 


>So now the rest of bands, and then band composite and supervised
>classification (I've found nice tutorial on youtube, so I'm gonna follow
>it, or I will try semi-automatic classification plugin for qgis).
> 
>Nikos, you've wrote "Each band is one single image. No matter its bitness,
>it is "normal" to appear "mono-chromatic" -- its "normal" to apply a grey
>scale." I know that grey scale is normal, but I didn't have, let's say "50
>shades of grey" ;) but only one shade, one color-no scale of colors.

Thanks for the details Joanna. I now understand better. After each
processing you can check the range of your image(s) via `r.info -r` and
or r.univar for basic descriptive stats.  If all looks fine (min value,
max value, mean and standard deviation show clearly there is useful
information in the queried image(s)), then it's only a color-table
issue.  You should only need to apply the correct color table via
r.colors.

>Forunately, Moritz was right, thanks a lot! Now it looks normal.

Sure. But consider what is your aim and if you are ok giving away
some portion of the radiometric details.

>And you wrote also that "the correct way is to not use the Digital Numbers
>directly. Rather, convert to reflectance, then do whatever you have to."
>So application of i.landsat.toar is correct, right?

Yes.
> 
>Sorry for all stupid/basic questions but this is my first serious time
>with grass and landsat image processing.

If you do request (from me, at least) to accept apologies, then accept
my apologies for my infinite silly questions I have asked in this list
:-)

Nikos


ps-  Please try to keep some flow-of-text from top-to-bottom when
replying in the list.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev