Re: [GRASS-dev] Issue with double conditional in r.mapcalc (WinGRASS) and real life test of the aconda 7.5dev on Mac

[Vaclav Petras]

Hi Yann,

great to hear that you had at least some success. Hopefully the following
info will help you narrow down the issue.

On Sun, Feb 18, 2018 at 2:45 PM, Yann Chemin 
wrote:

> I conducted a GRASS GIS course this week and we found some bugs on
> WinGRASS:
>
> r.mapcalc expression=if(case1,if(case2,Val2True,Val2False),Val1False))
>


The example lacks the name of the map. Is this intentional? See suggestions
in the manual page, maybe it will explain some details (note the
differences to G6):

https://grass.osgeo.org/grass74/manuals/r.mapcalc.html#program-use
https://grass.osgeo.org/grass74/manuals/r.mapcalc.html#usage-from-command-line
https://grass.osgeo.org/grass74/manuals/r.mapcalc.html#backwards-compatibility

I don't know why the nested if statement/function would make any
difference. What else you have tried?


>
> This expression will fail, note that the lack of quote is intentional, as
> it is a requirement to run simpler r.mapcalc statements in WinGRASS.
>


I think quotes are basically required since spaces around equal sign are
basically required. See the above links. Perhaps more explanation is needed
in the manual. It explicitly talks about single quotes and unix, but not
about Win or why (or why not double quotes). The things about equal sign
and spaces were added by me to clarify the differences between G6 and G7
syntax, but I did not focus on the Win vs unix differences there.

When in doubts on Win, there is always the GUI Map Calculator which accepts
the right-hand side of the expression.

On bug which is in GUI, which may or may not be reported, is that the
history eats quotes from the command, so reusing the commands needs
additional care.


>
> Also, we found that the use of || and && within a simple conditional
> statement also did not process anything and failed.
>


We had issues in the past in our courses with running r.mapcalc commands on
Win because of these, but recently, we had no issues and we settled on the
following syntax (examples from class):

r.mapcalc "elev_combined = if(y() < 224274. && x() > 637455., elevation,
elev_srtm_30m)"

r.mapcalc "low_elev_developed = if((elevation < 100 && elevation > 60) &&
(landuse96_28m == 1 || landuse96_28m == 2),1,null())"

r.mapcalc "urban1_30m = if(landuse96_28m == 1,1,0) + if(landuse96_28m ==
2,2,0)"

Best,
Vashek
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[GRASS GIS]

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+-
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Raster   |Version:  svn-releasebranch74
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+-

Comment (by neteler):

 Concerning LZ4 compression: Shall this be backported?

  * r71999 libgis: update lz4 to 1.8.0

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3499: Backport of new ZSTD compression

[GRASS GIS]

#3499: Backport of new ZSTD compression
--+-
 Reporter:  neteler   |  Owner:  grass-dev@…
 Type:  enhancement   | Status:  new
 Priority:  normal|  Milestone:  7.4.1
Component:  LibRaster |Version:  unspecified
 Keywords:  ZSTD compression  |CPU:  All
 Platform:  All   |
--+-
 Carried over from #2750

 Replying to [#2750 comment:69 neteler]:
 > Concerning ZSTD compression: backport candidate for 7.4.1.

 ... for this I identified
  * r71892  update documentation for GRASS compression methods
  * r71891 libraster: update for ZSTD, use new G_compress_bound()
  * r71890 libgis: add ZSTD (Zstandard) compression
  * r71889 add ZSTD (Zstandard) compression to the Make system

 Probably also helpful:
  * r72031 libgis: more informative messages when (de)compression fails
  * r72042 libgis: add warnings when writing compressed data fails

 Is anything missing from this list?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Issue with double conditional in r.mapcalc (WinGRASS) and real life test of the aconda 7.5dev on Mac

[Helmut Kudrnovsky]

>I conducted a GRASS GIS course this week and we found some bugs on WinGRASS: 

the subject of this report is _(WinGRASS)_ and _aconda 7.5dev on Mac_ 

which winGRASS version have you used? 7.4.0? 7.5dev? another version?



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Issue with double conditional in r.mapcalc (WinGRASS) and real life test of the aconda 7.5dev on Mac

[Helmut Kudrnovsky]

>We used the tutorial in grass=promo/tuorials/grassstarter, the script at the
end essentially, running on >Spearfish dataset. 

hopefully found the right cmds (easier would be posting directly the
commands here).

workflow here in winGRASS7.4.0:

r.buffer input=streams@PERMANENT output=bstreams500 distances=500
r.null map=bstreams500@yann null=0
r.buffer input=roads@PERMANENT output=broads500 distances=500
r.null map=broads500@yann null=0

r.mapcalc expression="rbstreams500 = if( bstreams500@yann == 2, 1, 0)"

r.info map=slope@PERMANENT 
[...]
|   Range of data:min = 0  max = 52.52016

r.mapcalc expression="s_sl = if( rbstreams500@yann == 1, if( slope <= 5, 2,
5), 0)"

>This expression will fail, note that the lack of quote is intentional, as
it is a requirement to run simpler >r.mapcalc statements in WinGRASS. 

r.info map=s_sl@yann

++
 | Map:  s_sl@yann  Date: Sun Feb 18 23:14:50 2018   
|
 | Mapset:   yann   Login of Creator: hkmyr  
|
 | Location: spearfish_grass70data_0 
|
 | DataBase: D:\grassdata
|
 | Title:s_sl
|
 | Timestamp: none   
|

||
 |   
|
 |   Type of Map:  raster   Number of Categories: 0  
|
 |   Data Type:CELL  
|
 |   Rows: 466   
|
 |   Columns:  633   
|
 |   Total Cells:  294978
|
 |Projection: UTM (zone 13)  
|
 |N:4928000S:4914020   Res:30
|
 |E: 609000W: 590010   Res:30
|
 |   Range of data:min = 0  max = 5  
|
 |   
|
 |   Data Description:   
|
 |generated by r.mapcalc 
|
 |   
|
 |   Comments:   
|
 |if(rbstreams500@yann == 1, if(slope <= 5, 2, 5), 0)
|
 |   
|

++

 r.stats -c -n input=s_sl@yann  
 
0 109746
2 41812
5 140733

what should be the expected result of your calculations? are these different
to my calculations in winGRASS7.4.0.

a well described workflow and expected results would be helpfull for testing
if winGRASS 7.4.0 really fails here?





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Issue with double conditional in r.mapcalc (WinGRASS) and real life test of the aconda 7.5dev on Mac

[Helmut Kudrnovsky]

>r.mapcalc expression=if(case1,if(case2,Val2True,Val2False),Val1False))
>
>This expression will fail, note that the lack of quote is intentional, as
it is a requirement to run simpler >r.mapcalc statements in WinGRASS. 

when, in winGRASS, I copy from r.mapcalc:

r.mapcalc expression="rbstreams500 = if( bstreams500@yann == 2, 1, 0)"

the term is quoted.

when I do in the wxGUI console

r.mapcalc expression=rbstreams500unquoted = if( bstreams500@yann == 2, 1, 0)

I get an "unable to parse..." error.

how do you conclude that "it is a requirement to run simpler r.mapcalc
statements in winGRASS"?





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Issue with double conditional in r.mapcalc (WinGRASS) and real life test of the aconda 7.5dev on Mac

[Yann Chemin]

I conducted a GRASS GIS course this week and we found some bugs on WinGRASS:

r.mapcalc expression=if(case1,if(case2,Val2True,Val2False),Val1False))

This expression will fail, note that the lack of quote is intentional, as it is 
a requirement to run simpler r.mapcalc statements in WinGRASS.

Also, we found that the use of || and && within a simple conditional statement 
also did not process anything and failed.

We had 25% Mac overall (group of 110 students), we installed the new aconda 
7.5dev and all the above processing worked perfectly. We also had an Ubuntu 
machine (not mine) with Artful default grass install (7.4?) which performed as 
well as the Mac, nothing much to say except from the render.py bug in d.rast 
inside a d.mon (submit ticket last week 
https://trac.osgeo.org/grass/ticket/3497).

We used the tutorial in grass=promo/tuorials/grassstarter, the script at the 
end essentially, running on Spearfish dataset.

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

Re: [GRASS-dev] [GRASS GIS] #2637: Get direction raster in clockwise degrees starting from the North

[GRASS GIS]

#2637: Get direction raster in clockwise degrees starting from the North
--+-
  Reporter:  cgravelm |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Raster   |Version:  7.0.0
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MacOSX
--+-

Comment (by mmetz):

 Replying to [comment:37 hellik]:
 > Replying to [comment:36 hellik]:
 > > Replying to [comment:35 hellik]:
 > > > > {{{
 > > > > 0 black
 > > > > 180 white
 > > > > 360 black
 > > > > }}}
 > > > >
 > > > > should work.
 > > >
 > > > this scheme looks good, see attached
 aspect_nflag_color_color_manual_set.png
 > >
 > > looking at aspect_nflag_color_color_manual_set.png, it seems to be
 just the other way around?

 try

 {{{
 0 white
 180 black
 360 white
 }}}

 IMHO it's a matter of taste if you make north white and south black or
 vice versa.
 >
 > it seems to be more a visual effect as the human eye is used to get an
 illumination in maps of top-left (?)

 Such an illumination applies to shaded reliefs, see e.g. the azimuth
 option of r.relief.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3496: v.in.pdal: does not compile with PDAL 1.6.0

[GRASS GIS]

#3496: v.in.pdal: does not compile with PDAL 1.6.0
--+
  Reporter:  felixg   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Vector   |Version:  svn-releasebranch74
Resolution:  fixed|   Keywords:  v.in.pdal, PDAL, lidar
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by neteler):

 * status:  new => closed
 * resolution:   => fixed


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3496: v.in.pdal: does not compile with PDAL 1.6.0

[GRASS GIS]

#3496: v.in.pdal: does not compile with PDAL 1.6.0
--+
  Reporter:  felixg   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Vector   |Version:  svn-releasebranch74
Resolution:   |   Keywords:  v.in.pdal, PDAL, lidar
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by neteler):

 * version:  unspecified => svn-releasebranch74
 * milestone:   => 7.4.1


Comment:

 Replying to [comment:2 wenzeslaus]:
 ...
 > This can be closed after backport to 7.4 (and maybe 7.2).

 Backported to 7.4 in r72253, closing.

 @felixg: thanks for the patch!

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3496: v.in.pdal: does not compile with PDAL 1.6.0

[GRASS GIS]

#3496: v.in.pdal: does not compile with PDAL 1.6.0
--+
  Reporter:  felixg   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  unspecified
Resolution:   |   Keywords:  v.in.pdal, PDAL, lidar
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by neteler):

 In [changeset:"72253" 72253]:
 {{{
 #!CommitTicketReference repository="" revision="72253"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496 and #2732 (author:
 felixg, trunk r72246) + GPL header added in r72245
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2732: Read lidar data as vector points using PDAL

[GRASS GIS]

#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  (none)
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.4.1
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 In [changeset:"72253" 72253]:
 {{{
 #!CommitTicketReference repository="" revision="72253"
 v.in.pdal: change API calls to PDAL 1.6.0, see #3496 and #2732 (author:
 felixg, trunk r72246) + GPL header added in r72245
 }}}

-- 
Ticket URL: 
GRASS GIS 

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