Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

[Blumentrath, Stefan]

Hi,

This discussion is actually a bit old, but maybe it is not too late to consider 
adding selected addons to trunk?

>From my personal user point of view the r.streams.* modules and r.geomorphon 
>are indeed top candidates for inclusion in core!

However, also:

i.segment.hierarchical (though manual is not yet complete)
v.class.mlpy (drawback: requires mlpy library) or v.class.ml and
r.randomforest
could nicely complement the image classification tools in GRASS.

r.gwr would strengthen the general modeling power of GRASS.

The wx.metadata modules would be very relevant for institutional users too, but 
I guess the currently numerous dependencies prohibit to move them to core...

Cheers
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Michael 
Barton
Sent: 5. juli 2016 00:06
To: GRASS developers 
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core

The r.stream* modules have been around for quite awhile and are very useful.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



On Jul 4, 2016, at 2:00 AM, 
grass-dev-requ...@lists.osgeo.org 
wrote:

From: Helmut Kudrnovsky >
Subject: Re: [GRASS-dev] Upcoming 7.2.0: review which addons to move to core
Date: July 3, 2016 at 1:25:20 PM MST
To: >


Markus Neteler wrote

Hi,

we may consider to move a few (!) mature addons to core.

Thoughts?

Markus

___
grass-dev mailing list


grass-dev@.osgeo


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] t.connect and t.rast.what not in GUI

[Blumentrath, Stefan]

Thanks Anna,

I just checked the new modules for 7.2.0 listed here:
https://trac.osgeo.org/grass/wiki/Release/7.2.0-News

And found that actually none of them seem to have made it into the GUI...
v.krige on the other hand is still in the GUI though it has been removed from 
the code...

I can try to create a new patch for that if you like...

Cheers
Stefan


-Original Message-
From: Anna Petrášová [mailto:kratocha...@gmail.com] 
Sent: 29. september 2016 15:20
To: Blumentrath, Stefan 
Cc: GRASS developers list (grass-dev@lists.osgeo.org) 

Subject: Re: [GRASS-dev] t.connect and t.rast.what not in GUI

On Wed, Sep 28, 2016 at 8:48 AM, Blumentrath, Stefan 
 wrote:
> Hi,
>
>
>
> It seems that t.connect and t.rast.what have not been added to the GUI 
> (both in G73 and G72)!
>
>
>
> Please find attached a patch where I tried to add them. Hope that is 
> the proper way.
>
>
>
> I placed t.connect under temporal, but it might be better suited under 
> Database, don’t now...
>
>

I added it there and backported to 7.2. Thank you!

Anna

>
> 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] t.connect and t.rast.what not in GUI

[Anna Petrášová]

On Thu, Sep 29, 2016 at 5:47 PM, Blumentrath, Stefan
 wrote:
> Thanks Anna,
>
> I just checked the new modules for 7.2.0 listed here:
> https://trac.osgeo.org/grass/wiki/Release/7.2.0-News
>
> And found that actually none of them seem to have made it into the GUI...
> v.krige on the other hand is still in the GUI though it has been removed from 
> the code...
>
> I can try to create a new patch for that if you like...

That would be great. I would omit g.gui.datacatalog, d.frame,
d.legend.vect and maybe some others, I don't think we have to have all
modules accessible from menu.

Thank you

>
> Cheers
> Stefan
>
>
> -Original Message-
> From: Anna Petrášová [mailto:kratocha...@gmail.com]
> Sent: 29. september 2016 15:20
> To: Blumentrath, Stefan 
> Cc: GRASS developers list (grass-dev@lists.osgeo.org) 
> 
> Subject: Re: [GRASS-dev] t.connect and t.rast.what not in GUI
>
> On Wed, Sep 28, 2016 at 8:48 AM, Blumentrath, Stefan 
>  wrote:
>> Hi,
>>
>>
>>
>> It seems that t.connect and t.rast.what have not been added to the GUI
>> (both in G73 and G72)!
>>
>>
>>
>> Please find attached a patch where I tried to add them. Hope that is
>> the proper way.
>>
>>
>>
>> I placed t.connect under temporal, but it might be better suited under
>> Database, don’t now...
>>
>>
>
> I added it there and backported to 7.2. Thank you!
>
> Anna
>
>>
>> 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] #2385: v.in.ogr doesn't use information from dblogin file about external PostgreSQL server

[GRASS GIS]

#2385: v.in.ogr doesn't use information from dblogin file about external
PostgreSQL server
-+-
  Reporter:  hemeybo |  Owner:  martinl
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Database|Version:  svn-releasebranch70
Resolution:  duplicate   |   Keywords:  v.in.ogr PostgreSQL db.login
 |  db.databases
   CPU:  x86-64  |   Platform:  Linux
-+-
Changes (by martinl):

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


Comment:

 Replying to [comment:10 mlennert]:
 > Is this a duplicate of #3167 ?

 Seems to be like that. Taking liberty to close the ticket. Feel free to
 reopen if needed.

--
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] #2960: db.login port parameter

[GRASS GIS]

#2960: db.login port parameter
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  major|  Milestone:  7.2.0
 Component:  Database |Version:  svn-trunk
Resolution:  fixed|   Keywords:  database, postgresql, db.login
   CPU:  Unspecified  |   Platform:  Unspecified
--+
Changes (by martinl):

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


Comment:

 Replying to [comment:5 mlennert]:
 > I imagine that this is the same issue as #3167 which was fixed. Could
 you see if you still have this issue ?

 Right, seems to be like that. I tested PG database cluster running on port
 5433.

 {{{
 db.login dri=pg data=db port=5433
 db.tables -p
 }}}

 Worked. Closing, feel free to re-open if needed.

--
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] #3169: use external shapelib

[GRASS GIS]

#3169: use external shapelib
--+-
  Reporter:  opoplawski   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.1
 Component:  LibVector|Version:  svn-releasebranch72
Resolution:   |   Keywords:  shapelib, OGR
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * keywords:   => shapelib, OGR
 * version:  7.0.4 => svn-releasebranch72
 * component:  Default => LibVector
 * milestone:  7.0.5 => 7.2.1


Comment:

 Replying to [ticket:3169 opoplawski]:
 > Is there any reason at this point to not compile against an external
 shapelib?

 AFAIR we picked shapelib many years ago from http://shapelib.maptools.org/
 (points to http://download.osgeo.org/shapelib/). The last release appears
 to be from 2012 since it then became part of OGR
 (https://trac.osgeo.org/gdal/browser/branches/2.1/gdal/ogr/ogrsf_frmts/shape).

 Here is what we changed after that (for some years we kept it in sync with
 OGR, then lost track due to the needed effort). For the procedure, see
 https://trac.osgeo.org/grass/browser/grass/trunk/lib/external/shapelib/README

 The real question is: cannot we call the shape driver via OGR interface
 and drop our own copy?

--
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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by annakrat):

 Replying to [comment:13 mlennert]:
 > Replying to [comment:12 annakrat]:
 > > I applied the patch in r69607.
 >
 > Thanks. So it works ? ;-)
 >
 On Linux yes, I haven't tried yet on Windows. But I don't see why it
 wouldn't.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#1603 (master - c6b12e9)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #1603
Status: Errored

Duration: 17 minutes and 55 seconds
Commit: c6b12e9 (master)
Author: Anna Petrášová
Message: wxGUI/xml: add t.connect and t.rast.what in menu (thanks to Stefan 
Blumentrath)

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@69608 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/47c99241543f...c6b12e99fd0d

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/163712268

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications


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

Re: [GRASS-dev] [GRASS GIS] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by mlennert):

 Replying to [comment:12 annakrat]:
 > I applied the patch in r69607.

 Thanks. So it works ? ;-)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] t.connect and t.rast.what not in GUI

[Anna Petrášová]

On Wed, Sep 28, 2016 at 8:48 AM, Blumentrath, Stefan
 wrote:
> Hi,
>
>
>
> It seems that t.connect and t.rast.what have not been added to the GUI (both
> in G73 and G72)!
>
>
>
> Please find attached a patch where I tried to add them. Hope that is the
> proper way.
>
>
>
> I placed t.connect under temporal, but it might be better suited under
> Database, don’t now...
>
>

I added it there and backported to 7.2. Thank you!

Anna

>
> 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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by annakrat):

 I applied the patch in r69607.

--
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] #2743: v.net.steiner core dump

[GRASS GIS]

#2743: v.net.steiner core dump
-+-
  Reporter:  clara   |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  7.0.0
Resolution:  fixed   |   Keywords:
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by marisn):

 Replying to [comment:5 mlennert]:
 > Can this be closed ?
 It is already closed as it was fixed for 7.0.x and 7.2.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] #3170: GRASS_BATCH_JOB does not tolerate path with spaces

[GRASS GIS]

#3170: GRASS_BATCH_JOB does not tolerate path with spaces
+-
 Reporter:  marisn  |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.2.1
Component:  Startup |Version:  svn-trunk
 Keywords:  grass.py, init  |CPU:  Unspecified
 Platform:  Unspecified |
+-
 It is not possible to execute any GRASS_BATCH_JOB script form a path
 containing spaces.
 {{{
 Executing 
 /bin/sh: /home/maris/my: No such file or directory
 }}}

 Quoting or shell escaping also doesn't work due to
 get_batch_job_from_env_variable checking file presence with os.access()

 Workaround is to change line 1351 of grass.py to read:
 {{{
 proc = Popen('"' + batch_job + '"', shell=True)
 }}}

 As quoting of path is a delicate issue and there have been fights in other
 parts of GRASS with Popen, I'll better leave for more experienced GRASS
 Pythonists to decide if such workaround can be considered safe or more
 serious changes are needed.

--
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] #2627: v.out.postgis uses wrong database name or port

[GRASS GIS]

#2627: v.out.postgis uses wrong database name or port
--+---
  Reporter:  wenzeslaus   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:  PostgreSQL, postgres, PostGIS
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 The handling of host and port info have changed (use db.login instead of
 db.connect for that info). Could you test whether this is still an issue
 for you in 7.2 ?

--
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] #2626: v.out.ogr does not suggest db.connect and db.login when not set

[GRASS GIS]

#2626: v.out.ogr does not suggest db.connect and db.login when not set
--+---
  Reporter:  wenzeslaus   |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  PostgreSQL, postgres, PostGIS
   CPU:  Unspecified  |   Platform:  Linux
--+---

Comment (by mlennert):

 This seems related to the issues discussed in #3167. Is this still an
 issue for you in 7.2 ?

--
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] #2574: v.surf.icw - not working with the last version of grass7

[GRASS GIS]

#2574: v.surf.icw - not working with the last version of grass7
--+-
  Reporter:  bhlevca  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Addons   |Version:  svn-trunk
Resolution:   |   Keywords:  v.surf.icw
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Could someone else test the proposed patch ?

--
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] #2504: Dotted line guiding digitization tool disappeared

[GRASS GIS]

#2504: Dotted line guiding digitization tool disappeared
--+-
  Reporter:  madi |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  digitizer
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mlennert):

 Madi,

 what is the status of this bug for you ? For me it is still exactly as
 described in the ML, i.e. the issue only appears after having been in the
 settings menu and disappears if I switch drawing tools.

--
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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by mlennert):

 Replying to [comment:10 sbl]:
 > Confirmed on Win7.
 >
 > g.remove type=rast pattern=MASK -f does not remove a map "mask" on
 Windows, while
 > g.remove -fi type=rast pattern=MASK does.

 Ok. I've attached a patch that AFAICT should check for Windows and then
 make the g.remove call case insensitive.

 Please test.

 Moritz

--
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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-
Changes (by mlennert):

 * Attachment "rmask_windows.diff" added.

 patch to make removal of 'MASK' raster map case insensitive on 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] #1761: v.net.steiner fails on a network with large number of intersections

[GRASS GIS]

#1761: v.net.steiner fails on a network with large number of intersections
---+---
  Reporter:  cmbarton  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Vector|Version:  svn-trunk
Resolution:|   Keywords:  v.net.steiner
   CPU:  All   |   Platform:  All
---+---

Comment (by cmbarton):

 Have not had a chance to test. Traveling and in conferences. Will try to
 do so when I get back. But it will be several weeks. Sorry

--
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] #2343: GRASS 7: "inf" values break insert statements in v.rast.stats

[GRASS GIS]

#2343: GRASS 7: "inf" values break insert statements in v.rast.stats
-+-
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Python  |Version:  svn-releasebranch70
Resolution:  fixed   |   Keywords:  v.rast.stats
   CPU:  All |   Platform:  All
-+-
Changes (by sbl):

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


Comment:

 Closing for now.

 Feel free to reopen if the current solution of replacing "Inf" "Nan" with
 NULL is not considered sufficient any more, e.g. because Inf and Nan show
 up more frequent and there is a practical need / application for
 distinguishing Inf from NULL.

--
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] #2447: G_legal_filename: Special characters allowed in filenames

[GRASS GIS]

#2447: G_legal_filename: Special characters allowed in filenames
-+--
  Reporter:  hcho|  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  LibGIS  |Version:  svn-trunk
Resolution:  |   Keywords:  G_legal_filename
   CPU:  All |   Platform:  All
-+--

Comment (by mlennert):

 It is not clear to me what needs to be done, here, if anything.

--
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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by sbl):

 Confirmed on Win7.

 g.remove type=rast pattern=MASK -f does not remove a map "mask" on
 Windows, while
 g.remove -fi type=rast pattern=MASK does.

--
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] #2445: r.mask -r removal not working in GRASS 7.1 svn r.62210

[GRASS GIS]

#2445: r.mask -r removal not working in GRASS 7.1 svn  r.62210
--+-
  Reporter:  baharmon |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.mask
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+-

Comment (by mlennert):

 Could anyone test this on Windows, i.e. create a raster file named mask
 (lowercase) and then attempt 'g.remove type=rast pattern=MASK -f' and
 'g.remove -i type=rast pattern=MASK' ?

 And if the first doesn't work, but the second does could the following
 lines in r.mask:


 {{{
 grass.run_command('g.remove', flags='f', quiet=True,
   type='raster', name='MASK')
 }}}

 be replaced by


 {{{
 grass.run_command('g.remove', flags='fi', quiet=True,
   type='raster', name='MASK')

 }}}

 if we are in 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] #3048: r.out.gdal does not write EPSG code of the projection

[GRASS GIS]

#3048: r.out.gdal does not write EPSG code of the projection
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.out.gdal
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by sbl):

 See also possibly related tickets for QGIS processing:
 https://hub.qgis.org/issues/11884 and https://hub.qgis.org/issues/14499

--
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] #2385: v.in.ogr doesn't use information from dblogin file about external PostgreSQL server

[GRASS GIS]

#2385: v.in.ogr doesn't use information from dblogin file about external
PostgreSQL server
-+-
  Reporter:  hemeybo |  Owner:  martinl
  Type:  defect  | Status:  assigned
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Database|Version:  svn-releasebranch70
Resolution:  |   Keywords:  v.in.ogr PostgreSQL db.login
 |  db.databases
   CPU:  x86-64  |   Platform:  Linux
-+-

Comment (by mlennert):

 Is this a duplicate of #3167 ?

--
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] #2343: GRASS 7: "inf" values break insert statements in v.rast.stats

[GRASS GIS]

#2343: GRASS 7: "inf" values break insert statements in v.rast.stats
-+-
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Python  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  v.rast.stats
   CPU:  All |   Platform:  All
-+-

Comment (by mlennert):

 I would suggest to close this ticket. Writing NULL instead of infinity
 seems an adequate behaviour to me.

--
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] #2743: v.net.steiner core dump

[GRASS GIS]

#2743: v.net.steiner core dump
-+-
  Reporter:  clara   |  Owner:  grass-dev@…
  Type:  defect  | Status:  closed
  Priority:  normal  |  Milestone:  7.2.0
 Component:  Vector  |Version:  7.0.0
Resolution:  fixed   |   Keywords:
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by mlennert):

 Can this be closed ?

--
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] #1761: v.net.steiner fails on a network with large number of intersections

[GRASS GIS]

#1761: v.net.steiner fails on a network with large number of intersections
---+---
  Reporter:  cmbarton  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.2.0
 Component:  Vector|Version:  svn-trunk
Resolution:|   Keywords:  v.net.steiner
   CPU:  All   |   Platform:  All
---+---

Comment (by mlennert):

 ping

--
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] #1096: wxModeler: r.mapcalc action should allow to insert maps

[GRASS GIS]

#1096: wxModeler: r.mapcalc action should allow to insert maps
--+-
  Reporter:  timmie   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:  invalid  |   Keywords:  modeler
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by mlennert):

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


Comment:

 As this "bug" is 6 years old, the description is not very clear and there
 have been no reactions in the last 6 years, I'm closing this bug as
 invalid.

--
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] #2960: db.login port parameter

[GRASS GIS]

#2960: db.login port parameter
--+
  Reporter:  lucadelu |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.2.0
 Component:  Database |Version:  svn-trunk
Resolution:   |   Keywords:  database, postgresql, db.login
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by mlennert):

 I imagine that this is the same issue as #3167 which was fixed. Could you
 see if you still have this issue ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 7.0.5 release planning

[Moritz Lennert]

On 28/09/16 23:30, Markus Neteler wrote:

New attempt in the right thread, sorry.

Hi,

the new db.login blocker got solved, thanks.
The question is if we need a new RC or go ahead?

Any objections to go ahead and release without new RC?


Please go ahead.

BTW: It would be nice to have some idea of how many people actually test 
RCs..


Moritz

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

[GRASS-dev] HPC support and implementation options

[Markus Neteler]

(I take liberty to fork this out from
Re: [GRASS-dev] Adding an expert mode to the parser
For the archive reference:
https://lists.osgeo.org/pipermail/grass-dev/2016-September/082520.html
)

On Sun, Sep 25, 2016 at 9:49 PM, Markus Neteler  wrote:
> On Wed, Sep 28, 2016 at 10:51 PM, Markus Metz  
> wrote:
>> On Thu, Sep 29, 2016 at 12:03 AM, Sören Gebbert 
>>  wrote:
>> [snip]
>>>
>>> As an example, when aiming at processing all Sentinel-2 tiles
>>> globally, we speak about currently 73000 scenes * up-to-16 tiles along
>>> with global data, analysis on top of other global data is more complex
>>> when doing each job in its own mapset and reintegrate it in a single
>>> target mapset as if able to process then in parallel in one mapset by
>>> simply specifying the respective region to the command of interest.
>>> Yes, different from the current paradigm and not for G7.
>>
>> from our common experience, I would say that creating separate mapsets
>> is a safety feature. If anything goes wrong with that particular
>> processing chain, cleaning up is easy, simply delete this particular
>> mapset and run the job again, if possible on a different host/node
>> (assuming that failed jobs are logged). Anyway, I would be surprised
>> if the overhead of opening a separate mapset is measurable when
>> processing all Sentinel-2 tiles globally.

Generally I agree and with our MODIS experience it worked fine on a
"standalone" cluster system with local disks in each blade.

>> Reintegration into a single
>> target mapset could cause problems with regard to IO saturation, but
>> in a HPC environment temporary data always need to be copied to a
>> final target location at some stage.

Yes, with at least 10Gb/s internal connection it worked decently.

>> The HPC system you are using now
>> is most probably quite different from the one we used previously, so
>> this is a lot of guessing, particularly about the storage location of
>> temporary data (no matter if it is the same mapset or a separate
>> mapset).

Indeed, one of the current systems we are using is completely
virtualized, i.e. all disks are attached via network which is AFAIK
even virtualized. Hence no dedicated resources but competition with
other unknown users in this system.
I still try to understand how to optimize things there...

> Imagine you have a tool that is able to distribute the processing of a large
> time series of satellite images across a cluster. Each node in the cluster
> should process a stack of r.mapcalc, r.series or r.neighbors commands in a
> local temporary mapset, that gets later merged into a single one. A single
> stack of commands may have hundreds of jobs that will run in a single
> temporary mapset. In this scenario you need separate region settings for
> each command in the stack, because of the different spatial extents of the
> satellite images. The size of the stack depends on the size of the time
> series (number of maps) and the number of available nodes.
>
> Having region setting options in the parser will make the implementation of
> such an approach much easier. Commands like t.rast.algebra and
> t.rast.neighbors will directly benefit from a region parser option, allowing
> the parallel processing of satellite image time series on a multi-core
> machine.

Yes - the key issue is that such virtualized cluster systems behave
quite differently compared to the bare metal system we used to have in
Italy.

> Best regards
> Soeren

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