r.mapcalculator and r.mapcalc

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

r.mapcalculator and r.mapcalc

Luiz Andrade
Hi there,
I have some questions regarding r.mapcalc questions:
1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.
2 - My r.mapcalc outputs int32 rasters (I want float32). Is there a way to choose the output type?

Thanks!

Regards,
Luiz Claudio





_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Helmut Kudrnovsky
>1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.

can't answer this one

>My r.mapcalc outputs int32 rasters (I want float32). Is there a way to choose the output type?

from the manual [1]

------------------------
[...]
Functions
The functions currently supported are listed in the table below. The type of the result is indicated in the last column. F means that the functions always results in a floating point value, I means that the function gives an integer result, and * indicates that the result is float if any of the arguments to the function are floating point values and integer if all arguments are integer.

[...]
Floating point values in the expression
Floating point values in the expression are handled in a special way. With arithmetic and logical operators, if either operand is float, the other is converted to float and the result of the operation is float. This means, in particular that division of integers results in a (truncated) integer, while division of floats results in an accurate floating point value. With functions of type * (see table above), the result is float if any argument is float, integer otherwise.

Note: If you calculate with integer numbers, the resulting map will be integer. If you want to get a float result, add the decimal point to integer number(s).

If you want floating point division, at least one of the arguments has to be a floating point value. Multiplying one of them by 1.0 will produce a floating-point result, as will using float():

      r.mapcalc "ndvi = float(lsat.4 - lsat.3) / (lsat.4 + lsat.3)"
[...]
------------------------

HTH

[1] https://grass.osgeo.org/grass73/manuals/r.mapcalc.html
best regards
Helmut
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

wenzeslaus
In reply to this post by Luiz Andrade

On Mon, Feb 20, 2017 at 4:22 PM, Luiz Andrade <[hidden email]> wrote:
1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.

Nobody really asked for that as far as I know. The porting should be quite simple if you are interested in that. But that was not the issue. See discussion here:
 
http://trac.osgeo.org/grass/ticket/2409#comment:190

QGIS seemed to focus more on providing good native QGIS calc:
Of course, these things can be reevaluated anytime. Ideally in a ticket.

If you learn or ask more about it somewhere else, please write it back. I would like to have the whole picture.

Vaclav

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Luiz Andrade
Thank you very much!
That was very helpful!

Atenciosamente,
Luiz Claudio




Em 20 de fev de 2017, à(s) 21:11, Vaclav Petras <[hidden email]> escreveu:


On Mon, Feb 20, 2017 at 4:22 PM, Luiz Andrade <[hidden email]> wrote:
1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.

Nobody really asked for that as far as I know. The porting should be quite simple if you are interested in that. But that was not the issue. See discussion here:
 
http://trac.osgeo.org/grass/ticket/2409#comment:190

QGIS seemed to focus more on providing good native QGIS calc:
Of course, these things can be reevaluated anytime. Ideally in a ticket.

If you learn or ask more about it somewhere else, please write it back. I would like to have the whole picture.

Vaclav


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Luiz Andrade
In reply to this post by Helmut Kudrnovsky
Thanks!
Can you help me with another thing?
My images have 15m pixels, after processing in r.mapcalc and exporting they have 62m pixels. How can I solve this?

Thanks again

Regards,
Luiz Claudio




Em 20 de fev de 2017, à(s) 18:42, Helmut Kudrnovsky <[hidden email]> escreveu:

1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from
within QGIS.

can't answer this one

My r.mapcalc outputs int32 rasters (I want float32). Is there a way to
choose the output type?

from the manual [1]

------------------------
[...]
Functions
The functions currently supported are listed in the table below. The type of
the result is indicated in the last column. F means that the functions
always results in a floating point value, I means that the function gives an
integer result, and * indicates that the result is float if any of the
arguments to the function are floating point values and integer if all
arguments are integer.

[...]
Floating point values in the expression
Floating point values in the expression are handled in a special way. With
arithmetic and logical operators, if either operand is float, the other is
converted to float and the result of the operation is float. This means, in
particular that division of integers results in a (truncated) integer, while
division of floats results in an accurate floating point value. With
functions of type * (see table above), the result is float if any argument
is float, integer otherwise.

Note: If you calculate with integer numbers, the resulting map will be
integer. If you want to get a float result, add the decimal point to integer
number(s).

If you want floating point division, at least one of the arguments has to be
a floating point value. Multiplying one of them by 1.0 will produce a
floating-point result, as will using float():

     r.mapcalc "ndvi = float(lsat.4 - lsat.3) / (lsat.4 + lsat.3)"
[...]
------------------------

HTH

[1] https://grass.osgeo.org/grass73/manuals/r.mapcalc.html



-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/r-mapcalculator-and-r-mapcalc-tp5308738p5308742.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Pedro Venâncio-2
In reply to this post by wenzeslaus
Hi Vaclav,

The problem with r.mapcalc in QGIS was this one:

https://hub.qgis.org/issues/6894

It was partially solved, but not completely. So, Victor had created a new raster calculator using native QGIS classes:

https://github.com/qgis/QGIS/pull/3779

Best regards,
Pedro




2017-02-21 0:11 GMT+00:00 Vaclav Petras <[hidden email]>:

On Mon, Feb 20, 2017 at 4:22 PM, Luiz Andrade <[hidden email]> wrote:
1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.

Nobody really asked for that as far as I know. The porting should be quite simple if you are interested in that. But that was not the issue. See discussion here:
 
http://trac.osgeo.org/grass/ticket/2409#comment:190

QGIS seemed to focus more on providing good native QGIS calc:
Of course, these things can be reevaluated anytime. Ideally in a ticket.

If you learn or ask more about it somewhere else, please write it back. I would like to have the whole picture.

Vaclav

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

wenzeslaus
Hi Pedro,

On Mon, Feb 20, 2017 at 7:36 PM, Pedro Venâncio <[hidden email]> wrote:
Hi Vaclav,

The problem with r.mapcalc in QGIS was this one:

https://hub.qgis.org/issues/6894


I forgot about this ticket. If I interpret the comments correctly there are still people who want r.mapcalculator despite its issues.

I also forgot about -l flag to list inputs and outputs in G7.2:

r.mapcalc "a = elevation + lakes" -l
output=a
input=elevation@PERMANENT,lakes@PERMANENT

It does not do the computation, it only lists the inputs and outputs. The was point to make writing the wrappers easier and more robust. See details here:
It was partially solved, but not completely. So, Victor had created a new raster calculator using native QGIS classes:

https://github.com/qgis/QGIS/pull/3779

Thanks for the info.
 


2017-02-21 0:11 GMT+00:00 Vaclav Petras <[hidden email]>:

On Mon, Feb 20, 2017 at 4:22 PM, Luiz Andrade <[hidden email]> wrote:
1 - Why wasn’t r.mapcalculator ported to grass7? It is great to use it from within QGIS.

Nobody really asked for that as far as I know. The porting should be quite simple if you are interested in that. But that was not the issue. See discussion here:
 
http://trac.osgeo.org/grass/ticket/2409#comment:190

QGIS seemed to focus more on providing good native QGIS calc:
Of course, these things can be reevaluated anytime. Ideally in a ticket.

If you learn or ask more about it somewhere else, please write it back. I would like to have the whole picture.

Vaclav

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user



_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Markus Neteler
In reply to this post by Luiz Andrade


On Feb 21, 2017 1:34 AM, "Luiz Andrade" <[hidden email]> wrote:
>
> Thanks!
> Can you help me with another thing?
> My images have 15m pixels, after processing in r.mapcalc and exporting they have 62m pixels. How can I solve this?

You will need to set the

https://grasswiki.osgeo.org/wiki/Computational_region

correctly.

Markus


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: r.mapcalculator and r.mapcalc

Luiz Andrade
Thank you very much!

In terms of best practices, if I work with several images with different resolutions, should I always set the region resolution before executing some raster calculation?
Or is it better to have different locations according to my images resolutions?

Thanks again!

Regards!

2017-02-21 3:44 GMT-03:00 Markus Neteler <[hidden email]>:


On Feb 21, 2017 1:34 AM, "Luiz Andrade" <[hidden email]> wrote:
>
> Thanks!
> Can you help me with another thing?
> My images have 15m pixels, after processing in r.mapcalc and exporting they have 62m pixels. How can I solve this?

You will need to set the

https://grasswiki.osgeo.org/wiki/Computational_region

correctly.

Markus



_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user