[GRASS-dev] [GRASS GIS] #3832: Add environment variable to create all temp-files at a user-defined location (outside the mapsets)

[GRASS GIS]

#3832: Add environment variable to create all temp-files at a user-defined
location (outside the mapsets)
---+-
 Reporter:  sbl|  Owner:  grass-dev@…
 Type:  enhancement| Status:  new
 Priority:  normal |  Milestone:  7.8.0
Component:  Default|Version:  svn-trunk
 Keywords:  environment variables  |CPU:  Unspecified
 Platform:  All|
---+-
 Some Network Attached Storage (NAS) filers with snapshot backup on volume
 level do not allow to exclude specific file types or directories to be
 excluded from backup.
 If GRASS data DB is stored on such a storage system, temporary files can
 grow the snapshot file significantly until a point where available space
 is used up by backup files (how fast that happens depends on the snapshot
 frequency of course, and the time they are preserved).


 Currently, it is not possible to redirect all temporary data to other
 storage locations. Would be great to have an environment variable that
 allows to specify a path (directory) where all temporary data will be
 stored.


 Might be necessary to make a subdirectory per mapset within that
 directory... (Maybe an 8.0 thing?)

-- 
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] #3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E

[GRASS GIS]

#3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  r.plane
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * version:  unspecified => svn-trunk


Old description:

> At time (besides the weird fact that the angle convention of azimuth does
> not match the standard GRASS convention) the easting and northing input
> does not accept sexagesimal input in lat-long location:
>
> {{{
> GRASS 7.2.0svn (latlong):~ >
> r.plane output=plane dip=45 azimuth=-9 \
>   easting=0:04:14.5E northing=48:52:14.5N elev=1000 type=CELL
> Traceback (most recent call last):
>   File "/home/neteler/software/grass72/dist.x86_64-pc-linux-
> gnu/scripts/r.plane", line 128, in 
> main()
>   File "/home/neteler/software/grass72/dist.x86_64-pc-linux-
> gnu/scripts/r.plane", line 78, in main
> ea = float(options['easting'])
> ValueError: invalid literal for float(): 0:04:14.5E
> }}}
>
> AFAIK G_OPT_M_COORDS would support that but here the values have to be
> specified separately.

New description:

 At time (besides the weird fact that the angle convention of azimuth does
 not match the standard GRASS convention) the easting and northing input
 does not accept sexagesimal input in lat-long location:

 {{{
 GRASS 7.2.0svn (latlong):~ >
 r.plane output=plane dip=45 azimuth=9 \
   easting=0:04:14.5E northing=48:52:14.5N elev=1000 type=CELL
 Traceback (most recent call last):
   File "/home/neteler/software/grass72/dist.x86_64-pc-linux-
 gnu/scripts/r.plane", line 128, in 
 main()
   File "/home/neteler/software/grass72/dist.x86_64-pc-linux-
 gnu/scripts/r.plane", line 78, in main
 ea = float(options['easting'])
 ValueError: invalid literal for float(): 0:04:14.5E
 }}}

 AFAIK G_OPT_M_COORDS would support that but here the values have to be
 specified separately.

--

Comment:

 Replying to [comment:5 lucadelu]:
 > Please look and try r74438

 Thanks, but now I get

 {{{
 r.plane output=plane dip=45 azimuth=9 easting=0:04:14.5E
 northing=48:52:14.5N elev=1000 type=CELL
 ERROR: Input coordinates seems to be invalid
 }}}

 With debug output added locally, I see that "E" and "N" are the problem
 (which are accepted in g.region, see
 https://grass.osgeo.org/grass76/manuals/g.region.html#changing-extent-and-
 raster-resolution-using-values):

 {{{
 r.plane output=plane dip=45 azimuth=9 easting="00:04:14.5E"
 northing="48:52:14.5N" elev=1000 type=CELL
 Traceback (most recent call last):
   File "/home/mneteler/software/grass77/dist.x86_64-pc-linux-
 gnu/scripts/r.plane", line 134, in 
 main()
   File "/home/mneteler/software/grass77/dist.x86_64-pc-linux-
 gnu/scripts/r.plane", line 84, in main
 print(gscript.utils.float_or_dms(options['easting']))
   File "/home/mneteler/software/grass77/dist.x86_64-pc-linux-
 gnu/etc/python/grass/script/utils.py", line 45, in float_or_dms
 return sum(float(x) / 60 ** n for (n, x) in enumerate(s.split(':')))
   File "/home/mneteler/software/grass77/dist.x86_64-pc-linux-
 gnu/etc/python/grass/script/utils.py", line 45, in 
 return sum(float(x) / 60 ** n for (n, x) in enumerate(s.split(':')))
 ValueError: invalid literal for float(): 14.5E

 # trying without "E":
 r.plane output=plane dip=45 azimuth=9 easting="00:04:14.5"
 northing="48:52:14.5N" elev=1000 type=CELL
 0.07069
 ERROR: Input coordinates seems to be invalid

 # trying without E and N:
 r.plane output=plane dip=45 azimuth=9 easting=00:04:14.5
 northing=48:52:14.5 elev=1000 type=CELL
   36%
 ...
 }}}

 IMHO float_or_dms() needs an update to accept E and N.

-- 
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] #2649: r.to.vect diagonals defect fixed

[GRASS GIS]

#2649: r.to.vect diagonals defect fixed
+-
  Reporter:  byronbest  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.6.2
 Component:  Raster |Version:  unspecified
Resolution: |   Keywords:  r.to.vect
   CPU:  x86-64 |   Platform:  All
+-

Comment (by byronbest):

 The algorithm builds lines grid cell by grid cell, scanning over the
 entire raster row by row.
 The resulting line features have a cell value and a line segment, one or
 more grid cells long.
 Without my patch, the routine builds the vertex lists, lengthening the
 diagonal and horizontal or vertical. This is incorrect when the grid cell
 value changes-- the result will have a long line with the value of the
 last cell in the diagonal chain, instead of shorter lines with consistent
 value.
 The code is already doing runs in horizontal and vertical correctly.

 Since the grid cell centers are the vertices of the result line, the value
 is associated with the segment from grid center to grid center
 neighboring, instead of the usual value change at the grid cell edges.
 However, for miles of line in each category, this is correct.

 You may argue that the start_line should specify node=1 but since node is
 unused anyway, I used 0.
 I suspect that it is also not correct with other value types, but I only
 tested categorical data.
 The bug would show in a line feature with the entire line given the value
 (elevation) or the last point in long runs diagonally.

-- 
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] #2649: r.to.vect diagonals defect fixed

[GRASS GIS]

#2649: r.to.vect diagonals defect fixed
+-
  Reporter:  byronbest  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.6.2
 Component:  Raster |Version:  unspecified
Resolution: |   Keywords:  r.to.vect
   CPU:  x86-64 |   Platform:  All
+-
Changes (by byronbest):

 * Attachment "line_stats.grass" added.

 mask and r.to.vect to make kml shapefile and csv by segment

-- 
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] #2649: r.to.vect diagonals defect fixed

[GRASS GIS]

#2649: r.to.vect diagonals defect fixed
+-
  Reporter:  byronbest  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.6.2
 Component:  Raster |Version:  unspecified
Resolution: |   Keywords:  r.to.vect
   CPU:  x86-64 |   Platform:  All
+-
Changes (by byronbest):

 * Attachment "alternative_line.grass" added.

 drain on cost surface to build mask of ideal path

-- 
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] #3831: d.grid: -g and -w flags do not display any grid

[GRASS GIS]

#3831: d.grid: -g and -w flags do not display any grid
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Display  |Version:  svn-releasebranch76
Resolution:   |   Keywords:  d.grid
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by Nikos Alexandris):

 Here, works using the PNG driver or the wxGUI. Unfortunately, in my setup,
 I cannot test a 'wx' monitor! But, isn't 'wx' essentially the same as the
 GUI?

 In a 'metric' Location:
 {{{
 g.proj -g
 name=Lambert Conformal Conic
 proj=lcc
 datum=nad83
 a=6378137.0
 es=0.006694380022900787
 lat_1=36.16
 lat_2=34.34
 lat_0=33.75
 lon_0=-79
 x_0=609601.22
 y_0=0
 no_defs=defined
 unit=Meter
 units=Meters
 meters=1
 }}}

 Grids drawn as expected via
 via
 {{{
 d.erase
 d.grid size=1000 color=red width=5 -b -t
 d.grid size=1 color=blue width=10 fontsize=20
 }}}
   https://i.imgur.com/Jm4WnLJ.png

 In instructing `-g`, units matter
 {{{
 d.grid size=0.05 -g color=green fontsize=20 width=10
 }}}
   - plain png output: https://i.imgur.com/M4g9OQY.png
   - in the wxGUI: https://i.imgur.com/G3mX7lu.png

-- 
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] #3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E

[GRASS GIS]

#3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  r.plane
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by lucadelu):

 Please look and try r74438

-- 
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] #2673: A more generic explanation of input on manual page of r.area

[GRASS GIS]

#2673: A more generic explanation of input on manual page of r.area
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Addons   |Version:  unspecified
Resolution:  wontfix  |   Keywords:  r.area
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by lucadelu):

 Anna fixed it in r73772

-- 
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] #3691: addon r.connectivity.distance not working

[GRASS GIS]

#3691: addon r.connectivity.distance not working
+
  Reporter:  cgarzon|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Addons |Version:  7.4.1
Resolution: |   Keywords:  r.connectivity
   CPU:  OSX/Intel  |   Platform:  MacOSX
+

Comment (by sbl):

 In [changeset:"74437" 74437]:
 {{{
 #!CommitTicketReference repository="" revision="74437"
 backport tempname function, see #3691
 }}}

-- 
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] #2735: t.rast.mapcalc input problem

[GRASS GIS]

#2735: t.rast.mapcalc input problem
--+
  Reporter:  leohardtke   |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.rast.mapcalc
   CPU:  Unspecified  |   Platform:  Linux
--+

Comment (by neteler):

 Replying to [comment:3 huhabla]:
 > However, please use t.rast.algebra instead. This module has other issues
 but is able to correctly identify space time datasets.

 Would it be possible to reimplement t.rast.mapcalc as a Python wrapper
 around G7:t.rast.algebra?

-- 
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] #3826: Fix doctests for Python 3

[GRASS GIS]

#3826: Fix doctests for Python 3
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:  gunittests,doctests,Python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by sbl):

 * version:  7.2.2 => svn-trunk


-- 
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] #2933: v.label issue

[GRASS GIS]

#2933: v.label issue
--+-
  Reporter:  vincent  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Vector   |Version:  svn-trunk
Resolution:  wontfix  |   Keywords:  v.label
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by vincent):

 You are right, now it works fine.

-- 
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] #3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E

[GRASS GIS]

#3225: r.plane: ValueError: invalid literal for float(): 0:04:14.5E
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  r.plane
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:3 neteler]:
 > I guess a Python equivalent of G_scan_easting() and G_scan_northing() is
 needed here.

 It's here:
 https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/utils.py#L33

-- 
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] #3491: i.group cannot read from other mapsets

[GRASS GIS]

#3491: i.group cannot read from other mapsets
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Imagery  |Version:  unspecified
Resolution:   |   Keywords:  i.group
   CPU:  All  |   Platform:  All
--+-
Changes (by sbl):

 * milestone:  7.2.4 => 7.8.0


Comment:

 Enhancement tickets should point to 7.8.

-- 
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] #3628: PyGRASS: Use GEOS buffering

[GRASS GIS]

#3628: PyGRASS: Use GEOS buffering
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  PyGRASS  |Version:  svn-trunk
Resolution:   |   Keywords:  buffer
   CPU:  All  |   Platform:  All
--+-
Changes (by sbl):

 * milestone:  7.4.5 => 7.6.2


Comment:

 Still relevant.

-- 
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] #3319: v.overlay: incorrect results with "not" operator

[GRASS GIS]

#3319: v.overlay: incorrect results with "not" operator
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  minor|  Milestone:  7.4.5
 Component:  Vector   |Version:  svn-releasebranch72
Resolution:  fixed|   Keywords:  v.overlay
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by sbl):

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


Comment:

 I have not come across more cases where this pops up.
 So, closing it.

-- 
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] #3071: v.db.join: fails with SQLite because of lower/UPPER case issues

[GRASS GIS]

#3071: v.db.join: fails with SQLite because of lower/UPPER case issues
--+
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:  vector,DB,join
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by sbl):

 * milestone:  7.2.4 => 7.6.2


Comment:

 Still relevant.
 The first patch would be a simple hack, that would have to be undone, if
 quoted identifiers were introduced.

-- 
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] #3490: pygrass: improve error messages for table handling

[GRASS GIS]

#3490: pygrass: improve error messages for table handling
-+---
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.2
 Component:  Python  |Version:  unspecified
Resolution:  |   Keywords:  pygrass,vector,SQLite
   CPU:  All |   Platform:  All
-+---
Changes (by sbl):

 * milestone:  7.2.4 => 7.6.2


-- 
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] #2418: t.unregister: circumvent OS limit for "maps"-parameter input (was: t.unregister: "maps"-parameter limited to ca. 5000 maps)

[GRASS GIS]

#2418: t.unregister: circumvent OS limit for "maps"-parameter input
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Temporal |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by sbl):

 * type:  defect => enhancement
 * milestone:  7.2.4 => 7.8.0


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Veronica Andreo]

Hola Martin,

El jue., 18 abr. 2019 a las 22:58, Martin Landa ()
escribió:

> Ciao,
>
> čt 18. 4. 2019 v 22:44 odesílatel Veronica Andreo 
> napsal:
> > It would be nice if the vector digitizer is fixed before release, see
> https://trac.osgeo.org/grass/ticket/3777.
>
> should be fixed in r74401.
>

partly... see https://trac.osgeo.org/grass/ticket/3777#comment:6

Thanks to you!! (for filling up our inboxes this weekend :D :D) Thanks for
your hard work!

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

Re: [GRASS-dev] [GRASS GIS] #3820: Error i.pansharpen in grass76 relbranch

[GRASS GIS]

#3820: Error i.pansharpen in grass76 relbranch
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Imagery  |Version:  svn-releasebranch76
Resolution:  fixed|   Keywords:  i.pansharpen
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by veroandreo):

 I confirm that the commit fixed the problem in relbranch.

 >So far, it is not designed to work in Python 3. I have not yet upgraded
 my computers so I can't yet test. A coming step will be to develop a new
 workflow to compile GRASS in Python 3.

 Will this help: https://trac.osgeo.org/grass/wiki/Python3Support#Howtotest
 ?

-- 
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] #2520: d.grid: -c and -d flags not displaying + and - marks

[GRASS GIS]

#2520: d.grid: -c and -d flags not displaying + and - marks
---+-
  Reporter:  richardc  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  normal|  Milestone:  7.0.7
 Component:  Display   |Version:  svn-trunk
Resolution:  fixed |   Keywords:  d.grid
   CPU:  x86-32|   Platform:  Linux
---+-
Changes (by veroandreo):

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


Comment:

 Originally reported bug seems to be fixed, therefore closing. For the bug
 regarding -g and -w flags, see #3831

-- 
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] #3831: d.grid: -g and -w flags do not display any grid

[GRASS GIS]

#3831: d.grid: -g and -w flags do not display any grid
+-
 Reporter:  veroandreo  |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.6.2
Component:  Display |Version:  svn-releasebranch76
 Keywords:  d.grid  |CPU:  Unspecified
 Platform:  Linux   |
+-
 I have tested in NC location and in an UTM location with no success.

 {{{
 d.mon wx0
 d.rast elevation
 d.grid -g size=100
 }}}

 Nothing, no error either. Tested in trunk and 76 relbranch.

-- 
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] #2989: g.gui.gmodeler - not possible to rename existing variable in model

[GRASS GIS]

#2989: g.gui.gmodeler - not possible to rename existing variable in model
+---
  Reporter:  lfurtkevicova  |  Owner:  grass-dev@…
  Type:  defect | Status:  reopened
  Priority:  normal |  Milestone:  7.6.2
 Component:  wxGUI  |Version:  svn-trunk
Resolution: |   Keywords:  gmodeler, variable rename
   CPU:  x86-64 |   Platform:  Linux
+---
Changes (by veroandreo):

 * status:  closed => reopened
 * 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] #2735: t.rast.mapcalc input problem

[GRASS GIS]

#2735: t.rast.mapcalc input problem
--+
  Reporter:  leohardtke   |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.rast.mapcalc
   CPU:  Unspecified  |   Platform:  Linux
--+

Comment (by veroandreo):

 This is still an issue in 7.6 relbranch. Here's how to reproduce:

 {{{
 # create strds test
 for i in `seq -w 1 10` ; do r.mapcalc expression="map_$i = 1" ; done
 t.create output=test type=strds temporaltype=absolute title="test"
 description="test"
 t.register input=test maps=`g.list rast pat=map_* sep=,`
 start='2000-01-01' increment="1 days" -i

 # create strds test2
 for i in `seq -w 1 10` ; do r.mapcalc expression="mapa_$i = 1" ; done
 t.create output=test2 type=strds temporaltype=absolute title="test"
 description="test"
 t.register input=test2 maps=`g.list rast pat=mapa_* sep=,`
 start='2000-01-01' increment="1 days" -i

 # t.rast.mapcalc
 t.rast.mapcalc inputs=test,test2 expression="test+test2" basename=test
 output=test3

 Starting temporal sampling...
 Starting mapcalc computation...
 Invalid map 
 Parse error
 ERROR: parse error
 ERROR: Error while mapcalc computation
 }}}

 maybe, this is a wontfix though... AFAIU, it is recommended to use
 G7:t.rast.algebra in these cases in which strds and maps within them are
 nested or so similar

-- 
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] #2957: t.rast.what throw error while running on large number of maps

[GRASS GIS]

#2957: t.rast.what throw error while running on large number of maps
--+---
  Reporter:  spareeth |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.4
 Component:  Temporal |Version:  svn-trunk
Resolution:  fixed|   Keywords:  temporal, t.rast.what
   CPU:  Unspecified  |   Platform:  Linux
--+---
Changes (by veroandreo):

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


Comment:

 Tested here in NC with 1000 maps:
 {{{
 for i in `seq -w 1 1000` ; do r.mapcalc expression="map_$i = 1" ; done
 t.create output=test type=strds temporaltype=absolute title="test"
 description="test"
 g.list rast pat=map_* output=list
 t.register input=test file=list start='2000-01-01' increment="1 days" -i
 t.rast.what coordinates=494637.096774,154319.556452 strds=test
 }}}

 all fine, no error reported. Closing.

-- 
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] #3227: g.gui.rlisetup: possibility to execute in command line ?

[GRASS GIS]

#3227: g.gui.rlisetup: possibility to execute in command line ?
--+-
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by tgrippa):

 Here is the function. It allows to create setup file for landscape
 polygons. If there are several base rasters (the categorical raster on
 which to compute landscape metrics using r.li), it allows for the creation
 of multiple setup file.

 I'm sure this function could be improved but at least has the merit of
 existing ;)


 {{{
 # Function that create the r.li configuration file for a list of
 landcover raster.
 ### It enable to create in one function as many configuration file as the
 number of raster provided in 'listoflandcoverraster'.
 ### It could be use only in case study with a several landcover raster and
 only one landscape unit layer.
 ### So, the landscape unit layer if fixed and there are the landcover
 raster which change.
 # 'listoflandcoverraster' wait for a list with the name (string) of
 landcover rasters.
 # 'landscape_polygons' wait for the name (string) of the vector layer
 containing the polygons to be used as landscape units.
 # 'masklayerhardcopy' wait for a boolean value (True/False) depending if
 the user want to create hard copy of the landscape units mask layers or
 not.
 # 'returnlistpath' wait for a boolean value (True/False) according to the
 fact that a list containing the path to the configuration files is
 desired.
 # 'ncores' wait for a integer corresponding to the number of desired cores
 to be used for parallelization.

 # Import GRASS lib
 import grass.script as gscript

 # Import libraries for multiprocessing
 import multiprocessing
 from multiprocessing import Pool
 from functools import partial

 # Function that copy the landscape unit raster masks on a new layer with
 name corresponding to the current 'landcover_raster'
 def
 
copy_landscapeunitmasks(current_landcover_raster,base_landcover_raster,landscape_polygons,landscapeunit_bbox,cat):
 ### Copy the landscape units mask for the current 'cat'
 # Define the name of the current "current_landscapeunit_rast" layer
 
current_landscapeunit_rast=current_landcover_raster.split("@")[0]+"_"+landscape_polygons.split("@")[0]+"_"+str(cat)
 
base_landscapeunit_rast=base_landcover_raster.split("@")[0]+"_"+landscape_polygons.split("@")[0]+"_"+str(cat)
 # Copy the the landscape unit created for the first landcover map in
 order to match the name of the current landcover map
 gscript.run_command('g.copy', overwrite=True, quiet=True,
 raster=(base_landscapeunit_rast,current_landscapeunit_rast))
 # Add the line to the text variable
 text="MASKEDOVERLAYAREA
 "+current_landscapeunit_rast+"|"+landscapeunit_bbox[cat]
 return text

 # Function that create the r.li configuration file for the base landcover
 raster and then for all the binary rasters
 def create_rli_configfile(listoflandcoverraster,landscape_polygons,
 masklayerhardcopy=False,returnlistpath=True,ncores=2):
 # Check if 'listoflandcoverraster' is not empty
 if len(listoflandcoverraster)==0:
 sys.exit("The list of landcover raster is empty and should contain
 at least one raster name")
 # Check if rasters provided in 'listoflandcoverraster' exists to avoid
 error in mutliprocessing
 for cur_rast in listoflandcoverraster:
 try:
 mpset=cur_rast.split("@")[1]
 except:
 mpset=""
 if cur_rast.split("@")[0] not in [x[0] for x in
 gscript.list_pairs(type='raster',mapset=mpset)]:
 sys.exit('Raster <%s> not found' %cur_rast)
 # Check if rasters provided in 'listoflandcoverraster' have the same
 extend and spatial resolution
 raster={}
 for x, rast in enumerate(raster_list):
 raster[x]=gscript.raster_info(rast)
 key_list=raster.keys()
 for x in key_list[1:]:
 for info in ('north','south','east','west','ewres','nsres'):
 if not raster[0][info]==raster[x][info]:
 sys.exit("Some raster provided in the list have different
 spatial resolution or extend, please check")
 # Get the version of GRASS GIS
 version=grass.version()['version'].split('.')[0]
 # Define the folder to save the r.li configuration files
 if sys.platform=="win32":
 rli_dir=os.path.join(os.environ['APPDATA'],"GRASS"+version,"r.li")
 else:
 rli_dir=os.path.join(os.environ['HOME'],".grass"+version,"r.li")
 if not os.path.exists(rli_dir):
 os.makedirs(rli_dir)
 ## Create an ordered list with the 'cat' value of landscape units to
 be processed.
 list_cat=[int(x) for x in gscript.parse_command('v.db.select',
 quiet=True,
 map

Re: [GRASS-dev] [GRASS GIS] #3227: g.gui.rlisetup: possibility to execute in command line ?

[GRASS GIS]

#3227: g.gui.rlisetup: possibility to execute in command line ?
--+-
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by veroandreo):

 Replying to [comment:5 tgrippa]:
 > Replying to [comment:4 martinl]:
 > > Still relevant?
 > Not relevant anymore. Finally, we bypass g.gui.rlisetup with a specific
 script in Python to create the setup files.

 Could you share how you did it? This is indeed interesting

-- 
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] #2989: g.gui.gmodeler - not possible to rename existing variable in model

[GRASS GIS]

#2989: g.gui.gmodeler - not possible to rename existing variable in model
+---
  Reporter:  lfurtkevicova  |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.6.2
 Component:  wxGUI  |Version:  svn-trunk
Resolution:  fixed  |   Keywords:  gmodeler, variable rename
   CPU:  x86-64 |   Platform:  Linux
+---

Comment (by veroandreo):

 If still relevant, why closing?

-- 
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] #3366: r.timestamp, support for ISO 8601 strings

[GRASS GIS]

#3366: r.timestamp, support for ISO 8601 strings
---+--
  Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  minor |  Milestone:  7.6.2
 Component:  Temporal  |Version:  unspecified
Resolution:|   Keywords:  timestamp, utc, iso 8601
   CPU:  Unspecified   |   Platform:  Unspecified
---+--

Comment (by veroandreo):

 I'd be interested in such a feature also in G7:t.register :)

-- 
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] #3221: r.cross output misses one category

[GRASS GIS]

#3221: r.cross output misses one category
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by veroandreo):

 IIUC, this was fixed in #72281.

 I tested in relbranch and I get a category 0 which is the product of the 2
 input maps:

 {{{
 r.cross -z input=landclass96@PERMANENT,geology_30m@PERMANENT output=test
 r.category map=test
 0   developed; CZfg
 1   developed; CZlg
 2   developed; CZig
 3   developed; CZbg
 ...
 }}}

-- 
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] #2933: v.label issue

[GRASS GIS]

#2933: v.label issue
--+-
  Reporter:  vincent  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.7
 Component:  Vector   |Version:  svn-trunk
Resolution:  wontfix  |   Keywords:  v.label
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by veroandreo):

 Here's how to test in NC

 {{{
 v.label map=railroads@PERMANENT column=OBJECTID where="OBJECTID >= 10800"
 labels=railroads
 d.mon wx0
 d.vect railroads
 d.labels railroads
 }}}

 Seems to work fine, it does respect the where condition. I'd better close
 as 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] #3117: d.mon wx0: GtK issues

[GRASS GIS]

#3117: d.mon wx0: GtK issues
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wx0, d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:17 mlennert]:
 > Replying to [comment:16 veroandreo]:
 > > Both in Fedora and Ubuntu...
 >
 > +Debian proper.
 >
 > The amount of clutter really depends on the the window size. In French
 locale, I have to enlargen the Map Display, for example, for the warnings
 to disappear. So, it seems that there is some issue with window sizes
 apparently calibrated for a specific locale, or for specific screen
 geometry.
 >
 > Using a tiling windows manager makes it even worse for me as windows
 float less, but are rather adapted to existing screen real estate.

 This comment should actually have gone to #3348, although I think the two
 are pretty much the same so could probably be merged.

-- 
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] #3117: d.mon wx0: GtK issues

[GRASS GIS]

#3117: d.mon wx0: GtK issues
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wx0, d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [comment:16 veroandreo]:
 > Both in Fedora and Ubuntu...

 +Debian proper.

 The amount of clutter really depends on the the window size. In French
 locale, I have to enlargen the Map Display, for example, for the warnings
 to disappear. So, it seems that there is some issue with window sizes
 apparently calibrated for a specific locale, or for specific screen
 geometry.

 Using a tiling windows manager makes it even worse for me as windows float
 less, but are rather adapted to existing screen real estate.

-- 
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] #3117: d.mon wx0: GtK issues

[GRASS GIS]

#3117: d.mon wx0: GtK issues
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wx0, d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by veroandreo):

 Both in Fedora and Ubuntu...

-- 
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] #2520: d.grid: -c and -d flags not displaying + and - marks

[GRASS GIS]

#2520: d.grid: -c and -d flags not displaying + and - marks
---+-
  Reporter:  richardc  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.0.7
 Component:  Display   |Version:  svn-trunk
Resolution:|   Keywords:  d.grid
   CPU:  x86-32|   Platform:  Linux
---+-

Comment (by veroandreo):

 Tested with grass 76 relbranch, both -c and -d flags work as expected,
 i.e., respective marks are shown.

 However, -g and -w do not work in UTM location either, no warning nor
 error displayed anywhere.

-- 
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] #2857: d.rast.num fails in GUI because the constrain display resolution fails

[GRASS GIS]

#2857: d.rast.num fails in GUI because the constrain display resolution fails
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.4.5
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  display resolution, d.rast.num,
   CPU:  |  mapdisp, rendering
  Unspecified|   Platform:  Linux
-+-

Comment (by veroandreo):

 I cannot reproduce the reported issue with grass 76 relbranch, I only get
 the usual warning when the region I try to show is larger than 200 x 200:

 {{{
 Failed to run command 'd.rast.num map=class_spot_dec2017_10c@dengue_cba'.
 Details:

 GRASS_INFO_WARNING(32567,1): Current region size: 1153 rows X 1793 cols

 GRASS_INFO_WARNING(32567,1): Your current region setting may be too large.
 Cells displayed on your graphics window may be too small for cell category
 number to be visible.
 GRASS_INFO_END(32567,1)

 GRASS_INFO_ERROR(32567,2): Aborting (region larger then 200 rows X 200
 cols is not allowed)
 GRASS_INFO_END(32567,2)
 }}}

 I'd suggest to close this one

-- 
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] #3269: r.roughness.vector: bug in rescale formula

[Carlos Henrique Grohmann de Carvalho]

I'll look into it this week

C

On Sun, Apr 28, 2019 at 7:37 PM GRASS GIS  wrote:

> #3269: r.roughness.vector: bug in rescale formula
> --+--
>   Reporter:  sbl  |  Owner:  grass-dev@…
>   Type:  defect   | Status:  new
>   Priority:  normal   |  Milestone:  7.2.4
>  Component:  Default  |Version:  unspecified
> Resolution:   |   Keywords:  AddOn,r.roughness.vector
>CPU:  Unspecified  |   Platform:  All
> --+--
>
> Comment (by neteler):
>
>  @guano: what's to be done here?
>
> --
> Ticket URL: 
> GRASS GIS 
>
>

-- 
Prof. Carlos Henrique Grohmann
Institute of Energy and Environment - Univ. of São Paulo, Brazil
- Digital Terrain Analysis | GIS | Remote Sensing -

http://carlosgrohmann.com
http://orcid.org/-0001-5073-5572

Can’t stop the signal.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3384: Ctypes detection doesn't work on OS X

[GRASS GIS]

#3384: Ctypes detection doesn't work on OS X
+--
  Reporter:  vince  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.8.0
 Component:  Compiling  |Version:  7.2.1
Resolution: |   Keywords:  Python Ctype
   CPU:  OSX/Intel  |   Platform:  MacOSX
+--

Comment (by vince):

 I’ll have a go later today and let you know

-- 
Ticket URL: 
GRASS GIS 

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