Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

[GRASS GIS]

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by annakrat):

 Replying to [comment:11 escheper]:
 >
 > Remains the following questions:
 > - How are other GRASS modules dealing with large grids? Do they have the
 same problem?
 > - What will be the impact on the output raster after changing some "="
 to "=="? Do we get different result buffers?
 > - In what way should I do a "pull request" of my changes in de code?

 [https://trac.osgeo.org/grass/wiki/HowToSVN#LocalDiffs Create a diff] and
 attach it here. You can make it simpler for us if you first identify the
 exact source of the error and then upload the patch which fixes without
 any extra changes. Changing int variables to long int might result in
 spending too much memory, so you shouldn't change it unless you consider
 the consequences.

 If you think there are other changes which need to be done to run r.buffer
 correctly, please explain them. For example, it's not clear why "=="
 should replace "=" and where. And yes, very probably we get then different
 results.
 >
 >
 >
 >

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3067: r.mapcalc gives wrong result when neighborhood modifier takes a cell above first

[GRASS GIS]

#3067: r.mapcalc gives wrong result when neighborhood modifier takes a cell 
above
first
--+--
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  blocker  |  Milestone:  7.0.5
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mapcalc, neighborhood modifier
   CPU:  Unspecified  |   Platform:  Linux
--+--

Comment (by marisn):

 I can confirm the issue with trunk r68709

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by annakrat):

 Also, please update your diff with changes I made to your previous diffs
 which are now committed. For example I changed the guisection of some new
 options and other things which I now see as removed in your diffs.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by annakrat):

 Replying to [comment:7 lazaa]:
 > I added flag {{{-l}}} for logarithmic  legend. I hadn't any good data so
 please feel free to test.

 you can also just compute flow accumulation with
 {{{
 r.watershed -a elevation=elevation threshold=1000 accumulation=flowacc
 }}}

 I tested it by setting labels 1,10,100,1000 and there should be the same
 distance between them, but it's not, so there must some mistake. See an
 example of logarithmic legend [http://i.stack.imgur.com/7VvVB.png here].

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by veroandreo):

 I will test as soon as your diff is applied, but if you wanna test, here's
 a link to the data with which I created the first attachment:

 https://dl.dropboxusercontent.com/u/59735456/chlorophyll_arg.tif

 Note that the problem in this case is that most of the map has very low
 values, so it would be important that the legend had more "space" for
 those values rather than for the rest of them that are rather few.

 I'm very happy that you are working on this :)

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GSoC: Basic cartography suite in GRASS - Week 4

[Adam Laža]

Hi all,

below is my fourth week report.

Best regards,
Adam

Wiki page:
https://trac.osgeo.org/grass/wiki/GSoC/2016/BasicCartographySuiteInGRASS

Week 4, June, 13 - 18

1. What did you get done this week?
I worked on the module d.legend.
I worked on ticket #3013[1]. I added background and border options and
option for title fontsize.
I worked on ticket #2714[2]. I added logarithmic legend for raster maps.

I worked on GUI/Workspace #2369[3]
I rewrote the code so now d.text module is used instead of wxPython text.


2. What do you plan on doing next week?
There's still a lot of work on GUI/Workspace with d.text.
I need to take few days off because I won't have access to my computer. I
suppose I will work more during weekend.

3. Are you blocked on anything?
Nope.

[1]: https://trac.osgeo.org/grass/ticket/3013
[2]: https://trac.osgeo.org/grass/ticket/2714
[3]: https://trac.osgeo.org/grass/ticket/2369
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-

Comment (by lazaa):

 I added flag {{{-l}}} for logarithmic  legend. I hadn't any good data so
 please feel free to test.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-
Changes (by lazaa):

 * Attachment "logleg.png" added.

 legend exa

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2714: wish: logarithmic legend for raster maps

[GRASS GIS]

#2714: wish: logarithmic legend for raster maps
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.legend, gsoc2016, cartography
   CPU:  x86-64   |   Platform:  All
--+-
Changes (by lazaa):

 * Attachment "log_leg.diff" added.

 Added {{{-l}}} flag for logarithmic legend

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GSoC 2016 - PyQt GRASS - Report 4

[Ondřej Pešek]

Hi all!

Here is the third report of my GSoC project - PyQt based GUI of GRASS
automatically generated from XML. For screenshots and other stuff se its
wiki: https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI

What did you get done this week?
* The Run button really runs (but still not with flags). It's still the
only button with any function. Also the code-string on the bottom of GUI
was recreated. Now it's just one (only readable) textedit. When the string
is too long, you will get the scrollbar.

* Completely retyped code in parameters.py. Now it works like Factory.
Factory is dynamically creating the list of methods classes with canHandle
method and the called class depends on the values in this method. It means
that there are not so many "ifs" and the code is better readable. And those
classes return "self" instead of method get().

* Float coords is lineedit.

* When the string has values, it's editable combobox with implemented
values.

* Nearly last thing: I implemented the TreeComboBox for inouts/outputs.
Both raster and vector. It works very similarly to the one in old GUI.
Mapset is parent and then you have many children to choose. It's in
gselect.py and in parameters.py is just the class inheriting it from
gselect with added canHandle method. It's much readable for anyone than
just directing program elsewhere. Now you can also choose the mapset; this
possibility will be banned in next coding.

* For not implemented thing I use lineedit (because You can write there
anything manually). Now I highlight it with red colour and word TODO in
GUI. It's just for me and will not be in the real version.

What do you plan on doing next week?
* I'm sorry but at June the 27th, I have my final exams for bachelor at
school so I won't be able to do anything related to GSoC in next week (I
really have to learn something before exams). I have done everything in my
timeline for next week so I hope it's okay. I will of course answer to
mails and such thing, I mean I will not be able to code anything. Thanks.

Thank you and have a sunny weekend!
Ondrej
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3062: Segmentation fault with r.buffer

[GRASS GIS]

#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-

Comment (by escheper):

 Replying to [comment:10 annakrat]:
 > I would say it is related to the fact that `to_ptr` is unsigned char, so
 it can overflow fast, although I don't understand the algorithm there.
 Note the comment in the code:
 > {{{
 > /* if MAPTYPE is changed to unsigned short, MAX_DIST can be set to
 2^16-2
 >  * (if short is 2 bytes)
 >  */
 > }}}
 > So I would try to change it to unsigned short. Unfortunately I can't
 easily test the testcase, I have little memory right now.


 Thanks to your tip I found the solution.

 Changing the MAPTYPE didn't solve the problem. But the problem was another
 overflow.

 I'm using a 64,800 x 129,600 grid which results in 8,398,080,000 cells (or
 bytes). This is far beyond the maxint (2,147,483,647) and causes the
 overflow.

 After changing most int variables in the r.buffer code in long types the
 segmentation fault disappeared :).

 I didn't check the output visually, that's what I need to do next. Having
 no segmentation fault is very promising.

 Except from changing the integer types to long, I have changed some "=" to
 "==" in "if" statements in process_left.c, process_at.c and
 process_rite.c. This didn't solve the segmentation fault but in my opinion
 the original code seems not to be correct.

 I found some other lines that may not be correct too. But I'm not sure
 about it. These lines are:

 {{{
 process_rite.c(90): *to_ptr = (first_zone = i) + ZONE_INCR;
 process_row.c(34): for (r = row; r >= 0 && (first_zone =
 find_distances(r)) >= 0; r--)
 process_row.c(47): r < window.rows && (first_zone = find_distances(r)) >=
 0; r++) {
 read_map.c(65): if ((*ptr++ = (*cell++ != 0))) {
 read_map.c(81): if ((*ptr++ = !Rast_is_c_null_value(cell++))) {
 }}}

 Can anyone confirm this?

 Remains the following questions:
 - How are other GRASS modules dealing with large grids? Do they have the
 same problem?
 - What will be the impact on the output raster after changing some "=" to
 "=="? Do we get other result buffers?
 - In what way should I do a "pull request" of my changes in de code.

--
Ticket URL: 
GRASS GIS 

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