Re: [GRASS-dev] [GRASS GIS] #3742: t.rast.aggregate: allow multiple methods/output

[GRASS GIS]

#3742: t.rast.aggregate: allow multiple methods/output
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.rast.aggregate
   CPU:  All  |   Platform:  All
--+--

Comment (by neteler):

 Replying to [comment:16 sbl]:
 > Thanks Markus, for your support. Just tried the latest revision and
 realized, that G_OPT_STRDS_OUTPUTS also changes the option name from
 "output" to "outputs".

 Well, it did not _change_ but it is an additional entry.

 > Would that be OK, or is that considered an API change?

 In which sense?

 > Python scripts, like the testsuite, will fail with: "ParameterError:
 output is not a valid parameter."...

 Please let me know where it fails exactly (or, where to see that).

-- 
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] #3742: t.rast.aggregate: allow multiple methods/output

[GRASS GIS]

#3742: t.rast.aggregate: allow multiple methods/output
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.rast.aggregate
   CPU:  All  |   Platform:  All
--+--

Comment (by sbl):

 Thanks Markus, for your support. Just tried the latest revision and
 realized, that G_OPT_STRDS_OUTPUTS also changes the option name from
 "output" to "outputs". Would that be OK, or is that considered an API
 change?

 Python scripts, like the testsuite, will fail with: "ParameterError:
 output is not a valid parameter."...

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Passed: GRASS-GIS/grass-ci#3344 (master - 028ebb7)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3344
Status: Passed

Duration: 11 mins and 5 secs
Commit: 028ebb7 (master)
Author: sbl
Message: Fix bug with quantles, clean printing

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/6451c5aa008d...028ebb74c9ff

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/505520162?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] Errored: GRASS-GIS/grass-ci#3343 (master - 6451c5a)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3343
Status: Errored

Duration: 11 mins and 23 secs
Commit: 6451c5a (master)
Author: Markus Neteler
Message: testsuite: use unique names on test modules to better support pytest 
(fixes #3792) (contributed by pmav99)

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/3c34c0062d13...6451c5aa008d

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/505476183?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

Re: [GRASS-dev] [GRASS GIS] #3792: Use unique names on test modules

[GRASS GIS]

#3792: Use unique names on test modules
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Tests|Version:  svn-trunk
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * component:  Default => Tests
 * milestone:   => 7.8.0


-- 
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] #3792: Use unique names on test modules

[GRASS GIS]

#3792: Use unique names on test modules
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  svn-trunk
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

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


Comment:

 In [changeset:"74226" 74226]:
 {{{
 #!CommitTicketReference repository="" revision="74226"
 testsuite: use unique names on test modules to better support pytest
 (fixes #3792) (contributed by pmav99)
 }}}

-- 
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] #3789: migrate trac issues to github

[GRASS GIS]

#3789: migrate trac issues to github
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:  svn, git, migration
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:2 martinl]:
 > PLEASE HELP TO REDUCE NUMBER OF OPEN ISSUES! Some of them are outdated,
 probably already fixed... Public review is very welcome, thanks!

 +1! Don't be shy, please check the open bug reports here.

 > BTW, we should probably start marking older releases by !EndOfLife term
 to be clear than no other releases are planned. What about keeping only
 two last release branches active. So:
 >
 > * 7.6.1 planned
 > * 7.4.5 planned
 > * 7.2 EOL (no 7.4.5 is planned)
 > * 7.0 EOL (no 7.0.7 is planned)
 >
 > Then we could change milestone of all EOL tickets to 7.6.1. (or 7.6.2)
 >
 > This should be done ideally before migration.

 Also +1. To declare EOL is fairly common.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Passed: GRASS-GIS/grass-ci#3342 (master - 3c34c00)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3342
Status: Passed

Duration: 9 mins and 55 secs
Commit: 3c34c00 (master)
Author: Markus Neteler
Message: python script core: shutil_which() exception fix for Python 3 (fixes 
#3773)

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/6314e0acf6d2...3c34c0062d13

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/505461689?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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 @sbl Skipping tests can be with
 [https://docs.python.org/2/library/unittest.html#skipping-tests-and-
 expected-failures this]. I haven't really tested how it works with
 gunittest, but my guess is that it should work out of the box.

-- 
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] #3773: shutil_which() throws an exception on Linux + Python 3

[GRASS GIS]

#3773: shutil_which() throws an exception on Linux + Python 3
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * status:  closed => reopened
 * resolution:  fixed =>
 * milestone:  7.8.0 => 8.0.0


Comment:

 Reopened with G8.0.0 milestone to remove TODO of r74225 in
 lib/python/script/core.py

-- 
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] #3773: shutil_which() throws an exception on Linux + Python 3

[GRASS GIS]

#3773: shutil_which() throws an exception on Linux + Python 3
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Python   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

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


Comment:

 In [changeset:"74225" 74225]:
 {{{
 #!CommitTicketReference repository="" revision="74225"
 python script core: shutil_which() exception fix for Python 3 (fixes
 #3773)
 }}}

-- 
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] #3791: r.stats.zonal with -r option

[GRASS GIS]

#3791: r.stats.zonal with -r option
--+-
  Reporter:  frankie  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  Raster   |Version:  7.2.0
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by frankie):

 I managed to work around as suggested, i.e. adding a rules= parameter to
 save the reclassing rules file, then mimic r.category with simple egrep
 clauses on the resulting rules set. At least it allows to have results in
 decent time. I also noticed that while a lot of rules associate -nan they
 are probably even processed in the r.reclass run. I agree that the right
 fix would be modifying the library function, but in the meantime this
 silly trick saved my butt :-)

-- 
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 + PROJ 6 + GDAL 2.5

[Markus Metz]

Dear Roger,

On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand  wrote:
>
> Since rgdal::make_EPSG() is facing the same problems of listing tabulated
> EPSG fields as g.proj -l, I was very happy to see Markus' code in
> g.proj/main.c mentioned in this thread, and have used this approach in
>
https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup&root=rgdal
>
> However, there are plenty of messages such as: "proj_as_proj_string:
> Unsupported conversion method: Lambert Conic Conformal (West
Orientated)". I
> haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
> also sees the same messages. If it does, maybe we could ask on the proj
list
> how they might be captured for summary reporting. I think they are coming
> from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906
in
> same file. Maybe PROJ now has an error handler that
>
> Another question concerns the issue of whether one needs to free objects
> created, in particular proj_crs_info and pj. Not so important for g.proj,
> which exists when done, but important for rgdal whose functions don't
exit.
>
> Anyway, very helpful to see that Markus is looking at the same issues as
we
> are!

Regarding parsing the traditional PROJ init files, I looked at pj_init.c in
PROJ 5 and earlier and attempted to improve parsing those traditional init
files in GRASS trunk r74224. I guess that R as well as GRASS is trying to
support PROJ versions from 4(.8) onwards.

Regards,

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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#3341 (master - 6314e0a)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3341
Status: Errored

Duration: 10 mins and 5 secs
Commit: 6314e0a (master)
Author: Markus Metz
Message: g.proj: attempt for a more general init file parser

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/2c3f11bb1b39...6314e0acf6d2

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/505412438?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

Re: [GRASS-dev] r.in.gdal with option configuration

[Pablo J. Zader]

Thanks. It work!  (Using GRASS GIS 77 )
Pablo

El mar., 12 mar. 2019 a las 15:06, Markus Metz (<
markus.metz.gisw...@gmail.com>) escribió:

>
>
> On Tue, Mar 12, 2019 at 6:51 PM Pablo J. Zader  wrote:
> >
> > Hi list
> >
> > Currently, I need to specify in the "r.in.gdal" command, certain
> configuration options provided by the gdal package. i.e .
> >  --config  
> > as described in the following report [1].
> >
> > Has this modification been implemented or is being implemented in any
> version of GRASS GIS?
> >
> > [1] https://trac.osgeo.org/grass/ticket/3413
> >
> Yes, it is available as r.in.gdal gdal_config= in GRASS 7.6+
>


-- 

Pablo J. Zader
Lic. en Cs. de la Computación + MSc. en Aplicaciones Espaciales de Alerta y
Respuesta Temprana a Emergencias
pablo.za...@gmail.com

Universidad Nacional de Córdoba
Av. Valpáraíso s/n Ciudad Universitaria
 [image: skype] [image: linkedIn]


*"Los Grandes Hombres hablan sobre ideas...  Los Hombres Promedio hablan
sobre cosas...  Los Hombres Pequeños hablan.. de otros Hombres.*

*del libro Matemática estas ahí? A. Paenza "*
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3413: r.in.gdal/v.in.ogr: add new config option to support GDAL/OGR configuration options

[GRASS GIS]

#3413: r.in.gdal/v.in.ogr: add new config option to support GDAL/OGR 
configuration
options
--+-
  Reporter:  mmetz|  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.6.1
 Component:  Datasets |Version:  svn-trunk
Resolution:  fixed|   Keywords:  GDAL/OGR import
   CPU:  All  |   Platform:  All
--+-
Changes (by mmetz):

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


Comment:

 Closing as fixed because GDAL configuration options can now be provided to
 r.in.gdal / v.in.ogr with the new gdal_config option in 7.6.

 Regarding [r|v].external, a new ticket should be created because it
 requires changes at library level.

 While at it, v.external should also support a simple spatial filter with a
 BBOX and where conditions.

-- 
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] #3773: shutil_which() throws an exception on Linux + Python 3

[GRASS GIS]

#3773: shutil_which() throws an exception on Linux + Python 3
--+-
  Reporter:  pmav99   |  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):

 If there are not any problems with the patch, please apply it. It is
 really needed when testing with Python 3.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.in.gdal with option configuration

[Markus Metz]

On Tue, Mar 12, 2019 at 6:51 PM Pablo J. Zader  wrote:
>
> Hi list
>
> Currently, I need to specify in the "r.in.gdal" command, certain
configuration options provided by the gdal package. i.e .
>  --config  
> as described in the following report [1].
>
> Has this modification been implemented or is being implemented in any
version of GRASS GIS?
>
> [1] https://trac.osgeo.org/grass/ticket/3413
>
Yes, it is available as r.in.gdal gdal_config= in GRASS 7.6+
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.in.gdal with option configuration

[Pablo J. Zader]

Hi list

Currently, I need to specify in the "r.in.gdal" command, certain
configuration options provided by the gdal package. i.e .
 --config  
as described in the following report [1].

Has this modification been implemented or is being implemented in any
version of GRASS GIS?

[1] https://trac.osgeo.org/grass/ticket/3413

Pablo

-- 

Pablo J. Zader
Lic. en Cs. de la Computación + MSc. en Aplicaciones Espaciales de Alerta y
Respuesta Temprana a Emergencias
pablo.za...@gmail.com

Universidad Nacional de Córdoba
Av. Valpáraíso s/n Ciudad Universitaria
 [image: skype] [image: linkedIn]


*"Los Grandes Hombres hablan sobre ideas...  Los Hombres Promedio hablan
sobre cosas...  Los Hombres Pequeños hablan.. de otros Hombres.*

*del libro Matemática estas ahí? A. Paenza "*
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3791: r.stats.zonal with -r option

[GRASS GIS]

#3791: r.stats.zonal with -r option
--+-
  Reporter:  frankie  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.5
 Component:  Raster   |Version:  7.2.0
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3791 frankie]:
 > When using a -r option to produce a reclassified output raster as
 result, the r.reclass call at the end of the program could be *extremely*
 inefficient. I tried with large maps  many thousands of cats (derived by
 r.clump) and I got very long running times.

 That's why the default is not to create reclass maps.
 >
 > Creating the rules files instead is very fast, even in those conditions.
 In many cases, it would be sufficient giving it as an (optional) output
 file and the r.reclass step could be avoided/postponed. BTW, undestanding
 why the r.reclass module could take ages would be nice, too.

 The reason is that the underlying library function to assign category
 labels `Rast_set_cat()` becomes terribly slow with an increasing number of
 categories. The relevant parts of the raster lib would need to be
 rewritten using a dynamic binary balanced search tree for a speed-up of
 raster category handling.

-- 
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] #3792: Use unique names on test modules

[GRASS GIS]

#3792: Use unique names on test modules
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:
Component:  Default  |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 I am experimenting a bit with running GRASS tests using pytest. If this
 works out, we should be able to e.g. easily get reports on
 [https://lists.osgeo.org/pipermail/grass-dev/2019-March/091482.html test
 coverage].

 One of the requirements for using pytest is to have
 [https://docs.pytest.org/en/latest/goodpractices.html#test-discovery
 uniquely named test modules]. The grass testsuite does have some
 duplicates filenames though. Regardless of  pytest, I think that having
 unique names is a good idea anyway.

 The following commands removes duplicate filenames and thus allow pytest
 to run:

 {{{
 svn mv lib/python/gunittest/testsuite/test_doctests.py
 lib/python/gunittest/testsuite/test_gunnitest_doctests.py
 svn mv lib/python/pygrass/gis/testsuite/test_doctests.py
 lib/python/pygrass/gis/testsuite/test_pygrass_gis_doctests.py
 svn mv lib/python/pygrass/messages/testsuite/test_doctests.py
 lib/python/pygrass/messages/testsuite/test_pygrass_messages_doctests.py
 svn mv lib/python/pygrass/modules/grid/testsuite/test_doctests.py
 lib/python/pygrass/modules/grid/testsuite/test_pygrass_modules_grid_doctests.py
 svn mv lib/python/pygrass/modules/interface/testsuite/test_doctests.py
 
lib/python/pygrass/modules/interface/testsuite/test_pygrass_modules_interface_doctests.py
 svn mv lib/python/pygrass/modules/testsuite/test_doctests.py
 lib/python/pygrass/modules/testsuite/test_pygrass_modules_doctests.py
 svn mv lib/python/pygrass/raster/testsuite/test_doctests.py
 lib/python/pygrass/raster/testsuite/test_pygrass_raster_doctests.py
 svn mv lib/python/pygrass/raster/testsuite/test_raster.py
 lib/python/pygrass/raster/testsuite/test_pygrass_raster.py
 svn mv lib/python/pygrass/rpc/testsuite/test_doctests.py
 lib/python/pygrass/rpc/testsuite/test_pygrass_rpc_doctests.py
 svn mv lib/python/pygrass/shell/testsuite/test_doctests.py
 lib/python/pygrass/shell/testsuite/test_pygrass_shell_doctests.py
 svn mv lib/python/pygrass/testsuite/test_doctests.py
 lib/python/pygrass/testsuite/test_pygrass_doctests.py
 svn mv lib/python/pygrass/vector/testsuite/test_doctests.py
 lib/python/pygrass/vector/testsuite/test_pygrass_vector_doctests.py
 svn mv lib/python/script/testsuite/test_doctests.py
 lib/python/script/testsuite/test_script_doctests.py
 svn mv lib/python/script/testsuite/test_raster.py
 lib/python/script/testsuite/test_script_raster.py
 svn mv lib/python/temporal/testsuite/test_doctests.py
 lib/python/temporal/testsuite/test_temporal_doctests.py
 svn mv temporal/t.rast.extract/testsuite/test_extract.py
 temporal/t.rast.extract/testsuite/test_t_rast_extract.py
 svn mv temporal/t.rast.univar/testsuite/test_univar.py
 temporal/t.rast.univar/testsuite/test_t_rast_univar.py
 svn mv temporal/t.rast3d.extract/testsuite/test_extract.py
 temporal/t.rast3d.extract/testsuite/test_t_rast3d_extract.py
 svn mv temporal/t.rast3d.univar/testsuite/test_univar.py
 temporal/t.rast3d.univar/testsuite/test_t_rast3d_univar.py
 svn mv vector/v.extract/testsuite/test_extract.py
 vector/v.extract/testsuite/test_v_extract.py
 svn mv vector/v.in.lidar/testsuite/basic_test.py
 vector/v.in.lidar/testsuite/test_v_in_lidar_basic.py
 svn mv vector/v.in.lidar/testsuite/filter_test.py
 vector/v.in.lidar/testsuite/test_v_in_lidar_filter.py
 svn mv vector/v.in.pdal/testsuite/basic_test.py
 vector/v.in.lidar/testsuite/test_v_in_pdal_basic.py
 svn mv vector/v.in.pdal/testsuite/filter_test.py
 vector/v.in.lidar/testsuite/test_v_in_pdal_filter.py
 }}}

 After applying, pytest is able
 [https://gist.github.com/pmav99/6a9f92ad3fbb0ef8d1fb8d71cb922af4 to
 collect] python based tests.

 Unless they are any specific objections, I would appreciate if this was
 applied.

-- 
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] #3791: r.stats.zonal with -r option

[GRASS GIS]

#3791: r.stats.zonal with -r option
-+-
 Reporter:  frankie  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.4.5
Component:  Raster   |Version:  7.2.0
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 When using a -r option to produce a reclassified output raster as result,
 the r.reclass call at the end of the program could be *extremely*
 inefficient. I tried with large maps  many thousands of cats (derived by
 r.clump) and I got very long running times.

 Creating the rules files instead is very fast, even in those conditions.
 In many cases, it would be sufficient giving it as an (optional) output
 file and the r.reclass step could be avoided/postponed. BTW, undestanding
 why the r.reclass module could take ages would be nice, too.

 Cheers,

 Frankie

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by cmbarton):

 * Attachment "i.pansharpen.py" added.


-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 I found a problem with the inverse PCA calculation and have fixed it. I'm
 uploading the revised version.

-- 
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] #3790: Cleanup gettext usage for python code

[GRASS GIS]

#3790: Cleanup gettext usage for python code
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pmav99):

 * Attachment "gettext_cleanup.diff" added.


-- 
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] #3790: Cleanup gettext usage for python code

[GRASS GIS]

#3790: Cleanup gettext usage for python code
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:
Component:  Python   |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 GRASS uses 3 translation domains:
 - grasslibs
 - grassmods
 - grasswxpy

 Calling {{{gettext.install()}}} injects {{{_()}}} in the builtins
 namespace thus making it globally available. To make i18n work, we should
 only need to call {{{gettext.install()}}} once per translation domain.

 The provided patch tries to simplify and centralize the usage of the
 gettext module in the python code. The main idea is that
 {{{lib/python/__init__.py}}} should be the one and only place where
 {{{getetx.install()}}} calls are being made. The direct consequence of
 this is that any python code that needs to use {{{_()}}} only needs to
 import the {{{grass}}} library first. This includes both the GUI code and
 the "scripts".

 The patch is attached and can be applied with:
 {{{
 patch -p0 < gettext_cleanup.diff
 }}}

 The changes can also be browsed [https://github.com/GRASS-GIS/grass-
 ci/pull/9 here].

 In order to test this you need to:

 1. Enable a non-english language locale on your OS. The exact way you do
 that depends on your distribution. French and German are probably the best
 options since AFAIK they have the most complete translations, but any
 supported language should work.
 2. Configure GRASS with NLS {{{--with-nls}}} and re-compile. If NLS was
 not previously enabled you need to run {{{make distclean}}} before
 configuring/compiling.
 3. Start a GRASS session with {{{LC_ALL=fr_FR.utf-8 ./bin.x86_64-pc-linux-
 gnu/grass77}}} (note you don't need to export any ENV variables; LC_ALL's
 purpose is specifically to override the values of all the other LC_*
 variables.[https://wiki.archlinux.org/index.php/Locale#LC_ALL:_troubleshooting
 source])
 4. your new session should now be in French. You should see the "text-
 based splash screen" in French. The command descriptions/options in french
 + the GUI in french. If not, that's a bug (or a missing translation!).

 What has not been tested is the doctests. I would appreciate if someone
 could verify that they work and/or provide info on how to run them.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

On Tue, Mar 12, 2019 at 11:51 AM Nikos Alexandris 
wrote:

> * Panagiotis Mavrogiorgos  [2019-03-12 02:39:01 +0200]:
>
> ..
>
> >I don't have GRASS installed. I always run it from bin.x86_64-pc-linux-gnu
> >too.
>
> Pano,
>
> I know you do, but just to verify again:
> you do `make distclean` before each fresh compilation, right?
>

I occasionally do, but not before each compilation. But you were right.
This fixed this. I expected that changes in "./configure" would somehow
propagate, but I was obviously wrong.
Thank you
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 Visually, after an `i.colors.enhance`, only PCA is a bit weird
 (https://i.imgur.com/VsASM4V.png). Brovey
 (https://i.imgur.com/d6QTSPK.png) and IHS
 (https://i.imgur.com/CXTN1bc.png) are more as epxected.

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 Michael,

 it works for me, i.e. 16-bit Landsat 8 bands used as input, are processed
 using the default method, and output 8-bit pan-sharpened bands.

 Here,

 {{{
 # input
 for RASTER in B8 B4 B5 B1 ;do echo $RASTER ;r.info -gr $RASTER ;echo ;done

 B8
 north=4423507.5
 south=4188892.5
 east=704707.5
 west=474292.5
 nsres=15
 ewres=15
 rows=15641
 cols=15361
 cells=240261401
 datatype=CELL
 ncats=0
 min=0
 max=65535

 B4
 north=4423515
 south=415
 east=704715
 west=474285
 nsres=30
 ewres=30
 rows=7821
 cols=7681
 cells=60073101
 datatype=CELL
 ncats=0
 min=0
 max=65535

 B5
 north=4423515
 south=415
 east=704715
 west=474285
 nsres=30
 ewres=30
 rows=7821
 cols=7681
 cells=60073101
 datatype=CELL
 ncats=0
 min=0
 max=65535

 B1
 north=4423515
 south=415
 east=704715
 west=474285
 nsres=30
 ewres=30
 rows=7821
 cols=7681
 cells=60073101
 datatype=CELL
 ncats=0
 min=0
 max=65535
 }}}

 and

 {{{
 #process
 i.pansharpen pan=B8 red=B4 green=B5 blue=B1 bitdepth=16 output=pan_ihs
 method=ihs --o
 i.pansharpen pan=B8 red=B4 green=B5 blue=B1 bitdepth=16 output=pan_brovey
 method=brovey --o
 i.pansharpen pan=B8 red=B4 green=B5 blue=B1 bitdepth=16 output=pan_pca
 method=pca --o
 }}}

 and
 {{{
 # output
 for RASTER in $(glr pattern=pan*) ;do echo $RASTER ;r.info -gr $RASTER
 ;echo ;done

 pan_brovey_blue
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=0
 max=21.8425196850394

 pan_brovey_green
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=0
 max=65.8663101604278

 pan_brovey_red
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=0
 max=28.5573122529644

 pan_ihs_blue
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=CELL
 ncats=0
 min=0
 max=77

 pan_ihs_green
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=CELL
 ncats=0
 min=0
 max=109

 pan_ihs_red
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=CELL
 ncats=0
 min=0
 max=87

 pan_pca_blue
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=31.40914130045
 max=96.916420771218

 pan_pca_green
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=44.8984732158751
 max=71.6383695727307

 pan_pca_red
 north=4315237.5
 south=4302412.5
 east=524647.5
 west=512302.5
 nsres=15
 ewres=15
 rows=855
 cols=823
 cells=703665
 datatype=DCELL
 ncats=0
 min=-41.5285779366908
 max=33.7977309887422
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Translations and command description/options

[Nikos Alexandris]

* Panagiotis Mavrogiorgos  [2019-03-12 02:39:01 +0200]:

..


I don't have GRASS installed. I always run it from bin.x86_64-pc-linux-gnu
too.


Pano,

I know you do, but just to verify again:
you do `make distclean` before each fresh compilation, right?

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

Re: [GRASS-dev] Looking for >8 bit satellite imagery to test

[Nikos Alexandris]

* Michael Barton  [2019-03-11 19:08:17 +]:


I ve updated I.pansharpen to handle imagery from 2-30 bit pixel depth
and would like to test it before committing it. Does anyone have high
bit depth imagery with a high resolution pan channel?  If anyone would
like to test this, let me know.


Michael,

Landsat-8 products are delivered as 16-bit.

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

Re: [GRASS-dev] [GRASS GIS] #3789: migrate trac issues to github

[GRASS GIS]

#3789: migrate trac issues to github
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:  svn, git, migration
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by martinl):

 Bearing in mind that probably only G7+ issues will be migrated, it's still
 a big number:

 {{{
 8.0.0+7.8.0+7.6.1+7.4.5+7.2.4+7.0.7

 42+32+325+48+144+163 -> 754
 }}}

 PLEASE HELP TO REDUCE NUMBER OF OPEN ISSUES! Some of them are outdated,
 probably already fixed... Public review is very welcome, thanks!

 BTW, we should probably start marking older releases by !EndOfLife term to
 be clear than no other releases are planned. What about keeping only two
 last release branches active. So:

 * 7.6.1 planned
 * 7.4.5 planned
 * 7.2 EOL (no 7.4.5 is planned)
 * 7.0 EOL (no 7.0.7 is planned)

 Then we could change milestone of all EOL tickets to 7.6.1. (or 7.6.2)

 This should be done ideally before migration.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Looking for >8 bit satellite imagery to test

[Markus Metz]

On Mon, Mar 11, 2019 at 10:09 PM Michael Barton 
wrote:
>
> So I downloaded this. What do I do with it? I have gdal 2.3.3 but it
doesn't list DIMAP or Spot as a format it recognizes.

This is strange because DIMAP has been available in GDAL since before
1.6.0, and the driver is compiled by default.

Markus M
>
> 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 Mar 11, 2019, at 9:27 PM, Markus Neteler  wrote:
>
> On Mon, Mar 11, 2019 at 8:19 PM Michael Barton 
wrote:
>
>
> I ve updated I.pansharpen to handle imagery from 2-30 bit pixel depth and
would like to test it before committing it. Does anyone have high bit depth
imagery with a high resolution pan channel?  If anyone would like to test
this, let me know.
>
>
> Here you can get Pléiades Primary Product - Bundle sample data:
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.intelligence-2Dairbusds.com_en_8262-2Dsample-2Dimagery&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=XyhXx0qAm4mxBzyNQRb5mCnDxQ6dJGvHia8elSHpBVk&s=luugHIFA1mecwd_YENgHazPRjZnPFSF1B6_iVRqa7ps&e=
>
> Location: Melbourne, Australia
> File format: JPEG 2000 12 bits - Regular compression
> Resolution: 0.5m PAN + 2m MS
> Spectral mode: Bundle (0.5m PAN + 2m MS 4 bands)
> Pre-processing level: Primary
> Date: 02/25/2012
>
> Best
> Markus
>
>
> --
> Markus Neteler, PhD
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mundialis.de&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=XyhXx0qAm4mxBzyNQRb5mCnDxQ6dJGvHia8elSHpBVk&s=laS9ldQFLND_77WKDdKkloY94RYDNPt3UKEJ1cmEskU&e=
- free data with free software
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__grass.osgeo.org&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=XyhXx0qAm4mxBzyNQRb5mCnDxQ6dJGvHia8elSHpBVk&s=wIl17Vxhkm-Tu5z4PIiIuuxVR-ZwwjQXO_xTiAOJvww&e=
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__courses.neteler.org_blog&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=XyhXx0qAm4mxBzyNQRb5mCnDxQ6dJGvHia8elSHpBVk&s=wOPKJkaDBFHrLpEcDO28fDlnlAXcl7jK9DBT9tBONz0&e=
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Looking for >8 bit satellite imagery to test

[Michael Barton]

Thanks Markus,

But I think this is only in gdal 2.5 and above. I don't have 2.5 yet because of 
its heavy dependency requirements, as others have mentioned.

While I can read the files as jpeg2000, I can't get GRASS to recognize the 
georeferencing.

Do you know of anyplace else I can get files that I can easily test this with? 
Geotifs would be nice.

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 Mar 12, 2019, at 12:11 AM, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:

On Mon, Mar 11, 2019 at 9:59 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:

So I downloaded this. What do I do with it? I have gdal 2.3.3 but it doesn't 
list DIMAP or Spot as a format it recognizes.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.gdal.org_frmt-5Fvarious.html-23DIMAP&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=Tx9ATk0SJF13_lzzP_Y_JF1WYIe9K_hqOr1PQk2us10&s=DNOE_BJBnZWo_A56HkVegtM9kor1wHC_zCOUVRrB4_k&e=
"This is a read-only read for Spot DIMAP described images. To use,
select the METADATA.DIM file in a product directory, or the product
directory itself."

If that doesn't work, please report it to GDAL.

Markus

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