Re: [GRASS-dev] [GRASS GIS] #3486: v.in.ogr/v.out.ogr: default format in online manual

[GRASS GIS]

#3486: v.in.ogr/v.out.ogr: default format in online manual
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  Docs |Version:  unspecified
Resolution:   |   Keywords:  v.out.ogr
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by Sylvain POULAIN):

 Problem is about wxgui sorry for this misunderstanding !
 With v.in.ogr, GPKG is not present in file listing but is present in
 directory (I didn't notice that until today). Even with that, you could
 not select gpkg from file with the GUI ("v.in.ogr -f | grep GPKG" is ok !)
 With r.out.gdal, it's not present in the list but could be changed
 manually. ("r.out.gdal -l | grep GPKG" is ok !

 But Idea is : some promotes gpkg but it's not in the totally support in
 Grass Gui (r.in.gdal is ok)

-- 
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] #3757: Python3: range vs xrange

[GRASS GIS]

#3757: Python3: range vs xrange
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 For the record, r74100 already replaces xrange with range in all important
 places. All these usages left are in documentation/comments so it's less
 important, I didn't do it mainly because I have some local changes so it
 was inconvenient.

-- 
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] #3179: g.extension not installing addons behind proxy

[GRASS GIS]

#3179: g.extension not installing addons behind proxy
--+
  Reporter:  madi |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:  g.extension, proxy, addons
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by neteler):

 Fix attempt via https://github.com/GRASS-GIS/grass-ci/pull/6 submitted as
 r74116.
 Note the different proxy syntax in the manual page.

 If ok, to be backported.

-- 
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] #3756: r.watershed: flow accumulation wrong with edge contamination

[GRASS GIS]

#3756: r.watershed: flow accumulation wrong with edge contamination
-+-
  Reporter:  itati01 |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Raster  |Version:  svn-releasebranch76
Resolution:  |   Keywords:  r.watershed, flow accumulation,
   CPU:  |  edge contamination
  Unspecified|   Platform:  Unspecified
-+-

Comment (by mmetz):

 Replying to [comment:2 itati01]:
 > Dear Markus,
 >
 > Thank you for your comment.
 >
 > I understand the problem with nodata cells in flow accumulation and
 would normally drop edge-contaminated cells. However, this is an
 exceptional use case, with nodata cells within the catchment.

 The same rule applies here too: any cell bordering a nodata cell does not
 distribute flow because it can not be determined where flow should be
 distributed to.

 > So, I used the flag -a hoping to obtain the number of upslope cells.

 The -a flag simply converts negative flow accumulation (receiving an
 unknown amount of flow) to positive flow accumulation.

 > I would like to ignore the nodata cells, and can actually do so because
 they form a channel (which I burned into the DEM to avoid artifical inflow
 from outside the watershed). So, there should really be no flow out of
 these nodata cells.

 This is correct, there will be no flow out of nodata cells. But there is
 an unknown amount of flow from nodata cells.

 > According to your explanation, my flow accumulation of -/+1 for cells 2
 and 6 within the rectangle in Figure 2 must be wrong. Cell 6, i.e. the 3rd
 cell in the 2nd row, only receives input from the 2 cells in row 3 which
 were correctly - as neighbors of nodata cells - set to -1. So, the weight
 of cell 6 should also be -1 (only flow from cells with nodata as neighbor)
 and the flow accumulation should be -/+3 - what I hoped to obtain.

 The other cells that might contribute to cell 6 are cells 8 and 9, both
 are edge-contaminated, thus cells 8 and 9 can not distribute flow, and
 thus flow accumulation of cell 6 is -1.

 > However, even with "regular" inflow, it would be nice to have an option
 to ignore edge contamination (feature request?).

 This would cause flow accumulation to follow edge-contaminated cells which
 is wrong. This could be easily demonstrated be setting the current region
 to a small subregion, calculate flow accumulation, then enlarge the
 region, calculate flow accumulation again, and compare the two results for
 flow accumulation. The result for the subregion would be obviously wrong.

 > Just assume, we have 4 upslope cells, of which 2 are edge contaminated.
 So, currently, we would get a flow accumulation of 1, not 5?

 No, if the other 2 upslope cells are not edge-contaminated, we would get a
 flow accumulation of 3 because the not edge-contaminated cells are allowed
 to distribute flow, also towards edge-contaminated cells.

 Regarding edge-contaminated cells, flow accumulation and flow direction
 are treated differently. Edge-contaminated cells can not distribute flow
 because this can cause flow to incorrectly follow edge-contaminated cells.
 Flow direction for edge-contaminated cells is set to another not-nodata
 cell if possible: the other cell is downstream, i.e. has a lower elevation
 value. The reason is that edge-contaminated cells most likely belong to
 the same catchment like a neighboring lower lying cell. Otherwise all
 edge-contaminated cells that do not receive flow accumulation from not
 edge-contaminated cells would form isolated single-cell catchments.

-- 
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] #3755: error when saving workspace in python 3

[GRASS GIS]

#3755: error when saving workspace in python 3
--+--
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:  fixed|   Keywords:  GUI, python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by veroandreo):

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


Comment:

 Thanks, works fine now :) Closing.

-- 
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] #3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress

[GRASS GIS]

#3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress
-+--
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Docs|Version:  svn-releasebranch76
Resolution:  |   Keywords:  r.compress,variables
   CPU:  All |   Platform:  All
-+--

Comment (by mmetz):

 In [changeset:"74115" 74115]:
 {{{
 #!CommitTicketReference repository="" revision="74115"
 update documentation with regard to ZSTD as default compression if
 available, see #3758 (backport trunk r74114)
 }}}

-- 
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] #3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress

[GRASS GIS]

#3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress
-+--
  Reporter:  sbl |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Docs|Version:  svn-releasebranch76
Resolution:  |   Keywords:  r.compress,variables
   CPU:  All |   Platform:  All
-+--

Comment (by mmetz):

 In [changeset:"74114" 74114]:
 {{{
 #!CommitTicketReference repository="" revision="74114"
 update documentation with regard to ZSTD as default compression if
 available, see #3758
 }}}

-- 
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] #3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress

[GRASS GIS]

#3758: zstd-suport in GRASS >= 7.6: update manuals for variables and r.compress
--+-
 Reporter:  sbl   |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:  7.6.1
Component:  Docs  |Version:  svn-releasebranch76
 Keywords:  r.compress,variables  |CPU:  All
 Platform:  All   |
--+-
 The release news for GRASS 7.6:
 https://trac.osgeo.org/grass/wiki/Release/7.6.0-News , say that new
 default raster compressor (if available) is ZSTD.

 Manuals for:
 * variables (https://grass.osgeo.org/grass76/manuals/variables.html)
 * r.compress (https://grass.osgeo.org/grass76/manuals/r.compress.html)
 * ???

 are not fully consistent/up to date in this regards and should be updated
 accordingly...

-- 
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] #3757: Python3: range vs xrange

[GRASS GIS]

#3757: Python3: range vs xrange
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Python 2 has both {{{range()}}} and {{{xrange()}}}.
 In Python 3, {{{range()}}} has been removed and {{{xrange()}}} has been
 renamed to {{{range()}}}.
 So any code using {{{xrange()}}} is not Python 3 compatible, so the answer
 is yes {{{xrange()}}} needs to be replaced by {{{range()}}}. This does
 lead to bigger RAM usage  ({{{range()}}} creates a list while
 {{{xrange()}}} creates an iterator, although in the vast majority of the
 cases the impact is negligible (and when it isn't you should probably
 rethink your algorithms).

 The alternative is to introduce a "compatibility layer". E.g.

 {{{
 import sys

 if sys.version_info.major < 3:
 range = xrange
 }}}

 but this needs to be used in every module (or added to a {{{compat.py}}}
 module and imported from any other module. Moreover, this can break
 something (if people were abusing {{{range()}}} that is).

 All that being said, when cross-version compatibility is required it is
 usually a good idea to use either six and/or future. I believe six is
 already being pulled by GRASS dependencies (matptlotlib if memory serves).

 https://pypi.org/project/six/
 https://pypi.org/project/future/

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Switching addon manual pages to point to grass76 ?

[Markus Neteler]

Hi,

On Fri, Feb 15, 2019 at 10:18 PM Markus Neteler  wrote:
> so far the addons still point to
> https://grass.osgeo.org/grass74/manuals/addons/
>
> Besides an Apache server rule change I have to do server-side, what
> else needs to be done?

ping

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

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#3287 (master - 4dfb103)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3287
Status: Fixed

Duration: 7 mins and 59 secs
Commit: 4dfb103 (master)
Author: Markus Neteler
Message: i.tasscap: declare encoding 
(https://www.python.org/dev/peps/pep-0263/) to avoid issue with accented char 
in comment

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/db8b4bb7a666...4dfb10349d41

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/495891618?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the GRASS-GIS/grass-ci repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=5458449&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific 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
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3757: Python3: range vs xrange

[GRASS GIS]

#3757: Python3: range vs xrange
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.8.0
Component:  Python   |Version:  svn-trunk
 Keywords:  python3  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 In r74088 xrange() was changed to range(). If that change is fine, should
 these other xrange() usages also be changed?

 {{{
 ag --python " in xrange"
 doc/python/raster_example_ctypes.py
 67:for row_n in xrange(rows):

 lib/python/temporal/abstract_space_time_dataset.py
 1146:>>> for i in xrange(3):

 lib/python/temporal/spatio_temporal_relationships.py
 423:#for i in xrange(len(maps)):
 425:#for j in xrange(offset, len(maps)):

 lib/python/pygrass/modules/interface/module.py
 64:>>> for i in xrange(5):
 87:>>> for i in xrange(5):
 111:>>> for i in xrange(3):

 lib/python/pygrass/raster/__init__.py
 412:>>> for row in xrange(map_a.info.rows):
 442:>>> for i in xrange(4):
 479:>>> for row in xrange(map_a.info.rows):
 480:... for col in xrange(map_a.info.cols):

 lib/python/pygrass/vector/basic.py
 384:>>> for cat in xrange(100, 110): cats.set(cat, layer=cat-50)

 lib/python/pygrass/vector/__init__.py
 87:#return (self.read(f_id) for f_id in
 xrange(self.num_of_features()))
 }}}

-- 
Ticket URL: 
GRASS GIS 

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