Re: [GRASS-dev] Regarding More Contributions

[Luca Delucchi]

On Sat, 21 Jul 2018 at 17:52, Sunveer Singh  wrote:
>
> Hi!
>

Hi Sunveer,

> Sorry I was not active for a long. But from now I will be giving my whole to 
> contribute.
>

sorry for the delay in the answer, but this summer is really busy

> What can I do? I have already written some tests for modules and I can write 
> more.
>

yes you can write more test or improve translation of your mother
language [0] or look to some simple issue [1]

> And if there is more stuff I can do please let me know.
>
> Thank you
> Sunveer

[0] https://www.transifex.com/grass-gis/grass7/dashboard/
[1] https://trac.osgeo.org/grass/report/1

-- 
ciao
Luca

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

Re: [GRASS-dev] [GRASS GIS] #3617: save display to image button broken

[GRASS GIS]

#3617: save display to image button broken
--+-
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.4.2
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by cmbarton):

 Because the cartographic composer doesn't work either in 7.4.1 and above,
 I'm escalating this to blocker because there is no way to get a map image
 out of GRASS.

-- 
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] #3617: save display to image button broken

[GRASS GIS]

#3617: save display to image button broken
--+-
  Reporter:  cmbarton |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.4.2
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by cmbarton):

 * priority:  major => blocker


-- 
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] #3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui

[GRASS GIS]

#3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui
--+---
  Reporter:  pvanbosgeo   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by martinl):

 Also G74:v.vect.stats related issue should be fixed in trunk (r73118,
 r73119). Testing welcome.

-- 
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] #3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui

[GRASS GIS]

#3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui
--+---
  Reporter:  pvanbosgeo   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by martinl):

 In [changeset:"73118" 73118]:
 {{{
 #!CommitTicketReference repository="" revision="73118"
 v.vect.stats: define gui dependencies, see #3619
 }}}

-- 
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] #3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui

[GRASS GIS]

#3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui
--+---
  Reporter:  pvanbosgeo   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by martinl):

 In [changeset:"73119" 73119]:
 {{{
 #!CommitTicketReference repository="" revision="73119"
 wxGUI forms: improve gui dependencies logic, see #3619
 }}}

-- 
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] #3623: wxGUI Layer Manager: changed display name of layer gets lost when layer properties are changed

[GRASS GIS]

#3623: wxGUI Layer Manager: changed display name of layer gets lost when layer
properties are changed
--+-
 Reporter:  mlennert  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.4.2
Component:  wxGUI |Version:  svn-trunk
 Keywords:  wxGUI layer display name  |CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 In the wxGUI Layer Manager, one can change the display name (right-click
 -> Rename). This can be very useful when displaying different subsets of a
 same map as different layers and using display names to identify which is
 which.

 However, whenever I change the properties of a layer, the display name
 falls back to the original map name and I have to rename it again. IMHO
 this is a bug and it should be up to the user to decide to rename the
 layer if necessary.

-- 
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] #3622: r.out.gdal export in USGSDEM format takes very long time and finally crashes

[GRASS GIS]

#3622: r.out.gdal export in USGSDEM format takes very long time and finally
crashes
-+-
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  critical|  Milestone:
 Component:  Raster  |Version:  7.4.0
Resolution:  |   Keywords:  r.out.gdal export USGSDEM long time
 |  crashes
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by dido):

 GeoTIFF export runs fine, producing a 10G file. I chose to export to USGS
 DEM because I expect a tenfold decrease in file size. At least that can be
 observed if I do a DEM export of the same 10G GeoTIFF using e.g.
 GlobalMapper.

 I don't have an idea if the MEM driver will handle raster this big. My PC
 has 16G of physical RAM and quite enough virtual memory.

 Precision loss is fine for me as the input raster is also int16. I suppose
 GRASS uses 64 bit floats internally (DCELL) and the truncation to int16
 will be handled by the export driver. Actually loss of speed due to
 truncation calculations is not an issue - GeoTIFF export runs for a quite
 reasonable time.

-- 
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] #3622: r.out.gdal export in USGSDEM format takes very long time and finally crashes

[GRASS GIS]

#3622: r.out.gdal export in USGSDEM format takes very long time and finally
crashes
-+-
  Reporter:  dido|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  critical|  Milestone:
 Component:  Raster  |Version:  7.4.0
Resolution:  |   Keywords:  r.out.gdal export USGSDEM long time
 |  crashes
   CPU:  x86-64  |   Platform:  MSWindows 7
-+-

Comment (by dnewcomb):

 Are you shooting for the ASCII USGSDEM format as described at
 https://www.gdal.org/frmt_usgsdem.html?

 From the message:
 >Driver  does not support direct writing. Using MEM driver for
 intermediate >dataset.
 Do you have enough memory to hold a 4 billion pixel raster in memory on
 the computer?
 See also
 https://www.gdal.org/frmt_mem.html
 Not sure if either the MEM driver or the USGS DEM format can handle 4
 billion pixels. Is there a reason that you can't use GeoTIFF ( up to 4GB
 file Size)for the output file or GeoTIFF with the BIGTIFF option? ( up to
 18,000 petabytes for a single file)

 If you are determined to do ascii file output, why not r.out.ascii,
 https://grass.osgeo.org/grass74/manuals/r.out.ascii.html ?


 >WARNING: Precision loss: Raster map
  of >type DCELL to be
 exported as Int16. This can be avoided by using Float64.

 If you are going to truncate to integer, it might be better to use the
 int() or round() functions in r.mapcalc prior to exporting.

-- 
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] #3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui

[GRASS GIS]

#3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui
--+---
  Reporter:  pvanbosgeo   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by martinl):

 This bug appears when you click on 'table' button before input vector map
 is selected. Steps to reproduce (in this case show on G74:v.extract):

 1. click on 'table' button (`where` option) -> reported traceback
  * fixed in r73114, error message "No vector map selected" appears
 2. select input map (with no attributes attached)
  * error message "No table linked to layer <1>"
 3. select input map with attributes attached
  * SQL Builder opens

 Anyway G74:v.vect.stats has another problem with GUI dependencies which
 needs to be 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] #3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui

[GRASS GIS]

#3619: G_OPT_DB_WHERE - non-functional 'table' icon in gui
--+---
  Reporter:  pvanbosgeo   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.4.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by martinl):

 In [changeset:"73114" 73114]:
 {{{
 #!CommitTicketReference repository="" revision="73114"
 G_OPT_DB_WHERE - non-functional 'table' icon in gui, see #3619
 }}}

-- 
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] #3622: r.out.gdal export in USGSDEM format takes very long time and finally crashes

[GRASS GIS]

#3622: r.out.gdal export in USGSDEM format takes very long time and finally
crashes
-+-
 Reporter:  dido |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  critical |  Milestone:
Component:  Raster   |Version:  7.4.0
 Keywords:  r.out.gdal export USGSDEM long time  |CPU:  x86-64
  crashes|
 Platform:  MSWindows 7  |
-+-
 I cannot attach any test raster because the one that manifests the problem
 is very large. Here I apply raster metadata (I suppose any raster of this
 size will do):

 {{{
 r.info map=BGMdem_8x8m_holes_filled_feathered@PERMANENT
 ++
  | Map:  BGMdem_8x8m_holes_filled_feat  Date: Fri Aug 17 13:30:15 2018
 |
  | Mapset:   PERMANENT  Login of Creator: a
 |
  | Location: BG_DEM
 |
  | DataBase: E:\mapping\GRASS7DB
 |
  | Title:BGMdem_8x8m_holes_filled_feathered
 |
  | Timestamp: none
 |
 ||
  |
 |
  |   Type of Map:  raster   Number of Categories: 0
 |
  |   Data Type:DCELL
 |
  |   Rows: 52101
 |
  |   Columns:  77901
 |
  |   Total Cells:  4058720001
 |
  |Projection: UTM (zone 35)
 |
  |N: 4928368.63825695S: 4511560.45143113   Res: 8.0359
 |
  |E: 663749.15806402W: 40538.62472039   Res: 8.3252
 |
  |   Range of data:min = -52.070711097653  max = 2925
 |
  |
 |
  |   Data Description:
 |
  |generated by r.mapcalc
 |
  |
 |
  |   Comments:
 |
  |if(isnull(defekti_rast_buf_recoded), BGMdem_8x8m_holes_filled,
 |
  |if(defekti_rast_buf_recoded < 100, BGMdem_8x8m_holes_filled * (100 -
 |
  |defekti_rast_buf_recoded) / 100 + ALOSdem_interp *
 |
  |defekti_rast_buf_recoded / 100, BGMdem_8x8m_holes_filled))
 |
  |
 |
 ++
 }}}

 At crash time progress indicator has not advanced at all. Tool output
 follows:

 {{{
 r.out.gdal -f --overwrite
 input=BGMdem_8x8m_holes_filled_feathered@PERMANENT output=E:\tmp\BGM-dem-
 f5p-csovp-wbf-cas-clgeo-s0_UTM_blended_20180816.dem format=USGSDEM
 type=Int16
 Driver  does not support direct writing. Using MEM driver for
 intermediate dataset.
 WARNING: Precision loss: Raster map
  of type DCELL to be
 exported as Int16. This can be avoided by using Float64.
 WARNING: Forcing raster export
 Checking GDAL data type and nodata value...
 Using GDAL data type 
 Input raster map contains cells with NULL-value (no-data). The value
 -32768 will be used to represent no-data values in the input map. You can
 specify a nodata value with the nodata option.
 Exporting raster data to USGSDEM format...
 }}}

-- 
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] #3413: r.in.gdal/v.in.ogr: add new config option to support GDAL/OGR configuration options

[GRASS GIS]

#3413: r.in.gdal/v.in.ogr: add new config option to support GDAL/OGR 
configuration
options
--+-
  Reporter:  mmetz|  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Datasets |Version:  svn-trunk
Resolution:   |   Keywords:  GDAL/OGR import
   CPU:  All  |   Platform:  All
--+-
Changes (by mmetz):

 * milestone:  7.4.2 => 7.6.0


Comment:

 Replying to [comment:3 neteler]:
 > How complicated would it be to implement this?

 It would be fairly simple for r.in.gdal/v.in.ogr.

 Regarding v.external/r.external, it would be more complicated because the
 raster and vector libraries need modifications.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] SOLVED: Trunk fails at configure phase on Ubuntu 18.04

[Maris Nartiss]

2018-08-15 23:19 GMT+03:00 Markus Neteler :
> That's strange. I recently updated the Dockerfile in trunk to use
> 18.04 and it works smoothly:
>
> https://hub.docker.com/r/neteler/grassgis7/~/dockerfile/
>
> Perhaps compare to your install procedure?
>
> Markus

Thanks, Markus.
As Docker didn't contain anything suspicious, I almost gave up but
decided to give the last shot to LC_ALL=C. Seems that I must set
LC_COLLATE=C before running ./configure. My previous value was
lv_LV.UTF-8.

Apparently my locale and GRASS build system do not play along nicely.

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