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.2.1
 Component:  wxGUI|Version:  svn-releasebranch72
Resolution:   |   Keywords:  wx0, d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [ticket:3117 neteler]:
 > I get a lot of warnings after having updated my laptop to Fedora 24:
 >
 >
 > {{{
 > d.mon wx0
 >
 > # startup: tons of these warnings
 > (main.py:6274): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion
 'size >= 0' failed in GtkCheckButton
 > ...
 > }}}

 Further analysis showed that this is a GTK and not a wxGTK error which
 also appears elsewhere.

 It seems to be this one:

 https://bugzilla.gnome.org/show_bug.cgi?id=765700

 -->
 https://github.com/GNOME/gtk/commit/ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a

 and here a workaround I found for meld:
 https://bugzilla.gnome.org/attachment.cgi?id=335456&action=diff

 Would a similar fix also help here (where to apply)?

--
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-user] r.to.vect stats

[Vaclav Petras]

[Switching from grass-user to grass-dev.]

On Mon, May 1, 2017 at 5:11 PM, Markus Metz 
wrote:

> > > Is it different from the binning code in r.in.xyz ?
> >
> >
> > Not really. r.in.lidar was based on r.in.xyz, now they are different
> but of course the idea is to make them again as similar as possible.
>
> I would rather keep r.in.xyz as simple as possible and instead add
> wrapper scripts for specific tasks. Maybe r.in.lidar could be sync'ed back
> to r.in.xyz and a new wrapper script could be created, something like
> r.in.lidar.filter ;-)
>

I was perhaps not clear enough. The code of r.in.lidar and r.in.xyz is the
same even now except for the separation of the binning code and LAS versus
ASCII. There is some filtering related to lidar, but I don't understand if
it is what you mean. Nevertheless, some filtering in r.in.xyz and getting
some functionality from r.in.lidar would make sense (as they are used
interchangeably depending on libLAS availability); unfortunately not really
making it simpler.


> > >
> > >>
> > >> Anyway, a new module needs to be implemented for this. The name can be
> > >> something like r.binning, r.vect.stats, r.point.stats, or
> > >> r.points.stats. It might good project for beginners.
> > >
> > >
> > > I like the idea. But do you really think this would be much faster
> than v.out.ascii | r.in.xyz ?
> >
> >
> > I don't know if much faster, but it will be at least little faster.
> Another issue is that "v.out.ascii | r.in.xyz" is little hard to do on MS
> Windows and from GUI in general. Yes, there should have been a wrapper
> module for this already, but the a module to do the task directly is seems
> to me as a better solution
>
> Why would a new C module be a better solution than a simple wrapper
> combining v.out.ascii + r.in.xyz? Considering code maintenance, a wrapper
> script would be easier to maintain. Otherwise, a dedicated C module would
> be another clone of r.in.xyz, taking as input not a text file but a GRASS
> vector with points.
>

I agree, script would be easier to maintain, but considering the
duplication between r.in.xyz and r.in.lidar (and possibly also r.in.pdal
which I haven't mentioned yet), I though moving the binning code to the
library and perhaps gaining some performance improvement along the way is a
better option.

But I'm not against a wrapper. I added a prototype with limited
functionality to addons [1]. However, I'm not sure how to account for large
data - that's what discouraged me from creating a wrapper. The Python
subprocess documentation says use communicate() but its doc says "The data
read is buffered in memory, so do not use this method if the data size is
large or unlimited." [2] Do I have to do the buffering myself then or is it
just fine? Is there some code like this in GRASS?

Thanks for the feedback,
Vaclav

[1] https://trac.osgeo.org/grass/changeset/70996
[2]
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4

[GRASS GIS]

#3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4
--+--
  Reporter:  msweier  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Addons   |Version:  7.0.4
Resolution:   |   Keywords:  r.stream, segmentation fault
   CPU:  Unspecified  |   Platform:  MacOSX
--+--

Comment (by mmetz):

 Replying to [ticket:3344 msweier]:
 > I'm getting a "Segmentation fault: 11" error when trying to run
 r.stream.slope in Grass 7.0.4 built via homebrew on macOS 10.12.4.
 r.stream.slope was installed using g.extension [...]

 Please update r.stream.slope for your GRASS 7.0.4 installation and test
 again. Preferably, update to GRASS 7.2 and install all needed addons anew.

--
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] #3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4

[GRASS GIS]

#3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4
--+--
  Reporter:  msweier  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  Addons   |Version:  7.0.4
Resolution:   |   Keywords:  r.stream, segmentation fault
   CPU:  Unspecified  |   Platform:  MacOSX
--+--

Comment (by martinl):

 Please provide exact command to replicate segfault. Ideally using NC
 dataset.

--
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] #3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4

[GRASS GIS]

#3344: r.stream.slope Segmentation fault: 11 error macOS 10.12.4
--+-
 Reporter:  msweier   |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.2.1
Component:  Addons|Version:  7.0.4
 Keywords:  r.stream, segmentation fault  |CPU:  Unspecified
 Platform:  MacOSX|
--+-
 I'm getting a "Segmentation fault: 11" error when trying to run
 r.stream.slope in Grass 7.0.4 built via homebrew on macOS 10.12.4.
 r.stream.slope was installed using g.extension via the command line and
 seems to work fine on grass 7.2.0 in my Windows 7 virtual machine.  Other
 r.stream addons seem to be working fine.  Can someone confirm this still
 exists in 7.2 on a mac?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.colors.enhance: G_calloc() error in r.quantile with large maps

[Markus Metz]

On Mon, May 1, 2017 at 11:17 AM, Markus Neteler  wrote:
>
> On Sun, Apr 30, 2017 at 10:39 PM, Markus Metz
>  wrote:
> ...
> > 16+GB of RAM still seems too much to me, unless the histograms of the
cell
> > values are highly skewed. What is the output of r.stats -c for B04_255,
> > B11_255, B8A_255?
>
> Since this comes from our automated processing chain I could only
> reimport the resulting S2 bands which should not change much.

If NULL values are correctly set, I would assume about 4 GB of RAM needed
by r.quantile.
If there are no NULL cells, I would assume about 14 GB of RAM which is
close to what you observed.

Can you check your processing chain to make sure the nodata value is
correctly set?

Also note that there are about 7 billion NULL cells in B04, but only 1.7
billion NULL cells in B8A and B11.

> I think they are (strongly) skewed: will send the data off-list to you.

The cell count for value 1 is quite high in all three bands. Is this
expected? However, the cell count for value 1 does not explain the high RAM
consumption of 16+ GB.

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

Re: [GRASS-dev] [GRASS GIS] #3340: wxGUI: encoding error when saving a workspace with vector that has accents in legend_label

[GRASS GIS]

#3340: wxGUI: encoding error when saving a workspace with vector that has 
accents
in legend_label
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  legend_label workspace
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mlennert):

 Is there some documentation about best practices in GUI programming
 concerning handling of encoding ?

--
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] #3275: wxGUI: encoding error when saving workspace

[GRASS GIS]

#3275: wxGUI: encoding error when saving workspace
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wxGUI workspace encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by mlennert):

 * milestone:  7.2.1 => 7.2.2


Comment:

 Replying to [comment:4 marisn]:
 > There have been fixes for #3340 related to encoding. At the moment
 loading/saving workspace with various non-latin chars seems to work fine.
 Can this be closed?

 r70531 still needs backporting so I would keep this ticket open until that
 has happened.
 Changing milestone to 7.2.2 to harmonize with the rest.

--
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] #3340: wxGUI: encoding error when saving a workspace with vector that has accents in legend_label

[GRASS GIS]

#3340: wxGUI: encoding error when saving a workspace with vector that has 
accents
in legend_label
--+
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  legend_label workspace
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mlennert):

 Replying to [comment:7 annakrat]:
 > Replying to [comment:3 mlennert]:
 > > Replying to [comment:1 annakrat]:
 > > > In [changeset:"70979" 70979]:
 > > > {{{
 > > > #!CommitTicketReference repository="" revision="70979"
 > > > wxGUI: fix encoding, see #3340
 > > > }}}
 > >
 > > Works great. Thanks for the quick fix !
 > >
 > > You changed the milestone to 7.2.2. I had the feeling that this is a
 quite small and pretty non-invasive fix of a standard bug. Don't you think
 it could still go into 7.2.1 ?
 >
 > Too close right now, I wouldn't be comfortable doing that especially
 because I haven't tested it on Windows.

 Ok. I agree. So we'll leave this open as a reminder for backport.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.colors.enhance: G_calloc() error in r.quantile with large maps

[Markus Neteler]

On Sun, Apr 30, 2017 at 10:39 PM, Markus Metz
 wrote:
...
> 16+GB of RAM still seems too much to me, unless the histograms of the cell
> values are highly skewed. What is the output of r.stats -c for B04_255,
> B11_255, B8A_255?

Since this comes from our automated processing chain I could only
reimport the resulting S2 bands which should not change much.
I think they are (strongly) skewed: will send the data off-list to you.

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