Re: [GRASS-dev] [GRASS GIS] #3104: Parallelize tools like r.cost

2016-07-18 Thread GRASS GIS 
#3104: Parallelize tools like r.cost
--+-
  Reporter:  belg4mit |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.cost
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by belg4mit):

 Hmm, the algorithm used is different than I imagined. However it seems
 like one possibility, although it would not necessarily scale easily
 beyond two cores, would be to have a pair of threads iterating over the
 raster cells: One beginning at the top left and the other working
 backwards from the bottom right.

--
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] #3104: Parallelize tools like r.cost

2016-07-18 Thread GRASS GIS 
#3104: Parallelize tools like r.cost
--+-
  Reporter:  belg4mit |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.cost
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3104 belg4mit]:
 > Currently QGIS will peg one of my cores while running r.cost. This
 leaves the system usable, but it also greatly slows down the execution
 time. Traversal of the cost raster should be readily parallelizable, and
 could divide the run time by the number of cores allocated.

 Can you provide hints about how r.cost could be parallelized? That would
 help a lot.

--
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] #2509: d.mon output overwrite

2016-07-18 Thread GRASS GIS 
#2509: d.mon output overwrite
--+-
  Reporter:  martinl  |  Owner:  martinl
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Display  |Version:  unspecified
Resolution:  fixed|   Keywords:  d.mon
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

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


Comment:

 Report issue has been solved already. Closing.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GUI: copy command in Python or R syntax

2016-07-18 Thread Anna Petrášová 
On Mon, Jul 18, 2016 at 11:49 AM, Blumentrath, Stefan
 wrote:
> Hei,
>
>
>
> In the light of the ongoing GSoC projects (esp. Web-GRASS) and recent
> questions regarding python syntax for GRASS commands, I was wondering what
> you think about the idea to offer the option to copy the command from the
> GUI (using the “Copy”-button) in other syntax than command line (e.g.
> defined by a environment variable let`s say: GRASS_CMD_COPY= (shell, python,
> R))?

This idea has been around for some time...
https://trac.osgeo.org/grass/ticket/2226

so let's continue the discussion there




>
>
>
> That would help novices like me to move to Python and if the Web-GIS GUI
> provides a jupyter interpreter, it might come in handy there too...
>
>
>
> Cheers
>
> Stefan
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
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

2016-07-18 Thread GRASS GIS 
#3062: Segmentation fault with r.buffer
---+-
  Reporter:  escheper  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  major |  Milestone:  7.0.5
 Component:  Raster|Version:  7.0.4
Resolution:|   Keywords:  r.buffer
   CPU:  Other |   Platform:  Linux
---+-
Changes (by annakrat):

 * priority:  blocker => major


Comment:

 No, it seems to be only problem with huge data.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] 7.0.5 release planning

2016-07-18 Thread Martin Landa 
Hi all,

as we are planning to release 7.0.5 in August [1] I suggest to start
with "Soft freeze of release branch" [2] today. Martin

[1] https://trac.osgeo.org/grass/milestone/7.0.5
[2] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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

2016-07-18 Thread 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 martinl):

 Is this really blocker for the release?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GUI: copy command in Python or R syntax

2016-07-18 Thread Blumentrath, Stefan 
Hei,

In the light of the ongoing GSoC projects (esp. Web-GRASS) and recent questions 
regarding python syntax for GRASS commands, I was wondering what you think 
about the idea to offer the option to copy the command from the GUI (using the 
"Copy"-button) in other syntax than command line (e.g. defined by a environment 
variable let`s say: GRASS_CMD_COPY= (shell, python, R))?

That would help novices like me to move to Python and if the Web-GIS GUI 
provides a jupyter interpreter, it might come in handy there too...

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-07-18 Thread GRASS GIS 
#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.3.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-
Changes (by martinl):

 * milestone:  7.2.0 => 7.3.0


--
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] #3081: Add text after labels in d.legend

2016-07-18 Thread GRASS GIS 
#3081: Add text after labels in d.legend
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  minor|  Milestone:  7.3.0
 Component:  Display  |Version:  unspecified
Resolution:  fixed|   Keywords:  d.legend, cartography
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by annakrat):

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


Comment:

 Committed in r69000.

--
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] #3103: vector import wizzard and v.in.ogr --ui fails to import a vector

2016-07-18 Thread GRASS GIS 
#3103: vector import wizzard and v.in.ogr --ui fails to import a vector
---+-
  Reporter:  hellik|  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  critical  |  Milestone:  7.3.0
 Component:  Vector|Version:  svn-trunk
Resolution:  fixed |   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 8
---+-
Changes (by annakrat):

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


Comment:

 In [changeset:"68999" 68999]:
 {{{
 #!CommitTicketReference repository="" revision="68999"
 wxGUI: fix #3103 - sys.maxsize doesn't work in 64bit windows
 }}}

--
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] #3104: Parallelize tools like r.cost

2016-07-18 Thread GRASS GIS 
#3104: Parallelize tools like r.cost
--+-
  Reporter:  belg4mit |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.cost
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

 * keywords:   => r.cost
 * component:  Default => Raster
 * milestone:  7.0.5 => 7.3.0


--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3104: Parallelize tools like r.cost

2016-07-18 Thread GRASS GIS 
#3104: Parallelize tools like r.cost
-+-
 Reporter:  belg4mit |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.0.5
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Currently QGIS will peg one of my cores while running r.cost. This leaves
 the system usable, but it also greatly slows down the execution time.
 Traversal of the cost raster should be readily parallelizable, and could
 divide the run time by the number of cores allocated.

--
Ticket URL: 
GRASS GIS 

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