Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

2019-03-07 Thread Nikos Alexandris 

Markus Metz:


The GUI is now (r74175) no longer reading the file share/proj/epsg which
no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get
the list of EPSG codes. This is important e.g. for the location wizard to
provide a list of known EPSG codes.


Obviously, this works also in the TUI (aka the command line) and looks
great!

→ g.proj list_codes=EPSG |grep 2100
2100|GGRS87 / Greek Grid|+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=50 
+y_0=0 +datum=GGRS87 +units=m +no_defs
3035|ETRS89 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 
+y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
5633|PTRA08 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 
+y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
5635|REGCAN95 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 
+y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
5636|TUREF / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 
+y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
5638|ISN2004 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 
+y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
32100|NAD83 / Montana|+proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 
+x_0=60 +y_0=0 +datum=NAD83 +units=m +no_defs


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

[GRASS-dev] g.proj -f does not work for all print options

2019-03-07 Thread Nikos Alexandris 

I was testing g.proj from trunk now, and there is this:

```
g.proj -f
ERROR: No output format specified, define one of flags -p, -g, -j, or -w
```

whereas only `-fj` and `-fw` will work. `-fp`, `-fg` do not get
flattened.

Nikos
___
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

2019-03-07 Thread 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):

 Thanks Michael, I've skimmed through.


 1. What justifies the assumption at
 https://trac.osgeo.org/grass/attachment/ticket/2048/i.pansharpen2#L138 and
 L139?

 Instead, what about returning an error, if the input bitness of an image
 is incompatible with what the program can handle, or at least, issue a big
 Warning to the user.


 2. https://trac.osgeo.org/grass/attachment/ticket/2048/i.pansharpen2#L152
 forces 8-bit range.

 Hopefully we can address this too by using something like the modified
 versions of i.rgb.his and i.his.rgb (as demonstrated here
 https://trac.osgeo.org/grass/ticket/774#comment:13). There is no
 mathematical constrain to force an 8-bit range. At least not for IHS and
 PCA. Is there?  Regarding "Brovey", the only assumption I can find by
 quickly searching on the internet, is "It assumes that the spectral range
 spanned by the panchromatic image is the same as that covered by the
 multispectral channels." (source:
 https://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images
 /fundamentals-of-panchromatic-sharpening.htm).

-- 
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

2019-03-07 Thread 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've attached an updated version of i.pansharpen (i.pansharpen2 here) that
 works with 8-32bit imagery. I've tested with artificially inflated bit
 depth images (8bit landsat rescaled to 11bit) and it seems to work fine.
 I'd appreciate it if others could test with imagery that is >8bit.

-- 
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

2019-03-07 Thread 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.pansharpen2" added.

 i.pansharpen updated to allow for 8-32 bit imagery

-- 
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] #3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are failing

2019-03-07 Thread GRASS GIS 
#3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are
failing
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Probably not. That issue is 3 months old while the regression in this case
 happened two weeks ago.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Fixed: GRASS-GIS/grass-ci#3313 (master - 1fbb6bc)

2019-03-07 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #3313
Status: Fixed

Duration: 14 mins and 41 secs
Commit: 1fbb6bc (master)
Author: Markus Metz
Message: g.proj: need GRASS_PROJSHARE to list codes with PROJ 4

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/d76f9f911d80...1fbb6bc6a150

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/503217390?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] #3783: Python 3: ./raster/r.patch/testsuite/test_rpatch_artificial.py is broken

2019-03-07 Thread GRASS GIS 
#3783: Python 3: ./raster/r.patch/testsuite/test_rpatch_artificial.py is broken
--+-
  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 neteler):

 It is difficult to extract patches from the text description of trac.
 Would you mind to attach them to the ticket as attachments?

 (yes, I am also looking fwd to migrate to git)

-- 
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

2019-03-07 Thread Markus Metz 
On Thu, Mar 7, 2019 at 5:17 PM Markus Metz 
wrote:
>
>
>
> On Mon, Feb 25, 2019 at 9:42 PM Even Rouault 
wrote:
> >
> > On lundi 25 février 2019 15:10:10 CET Markus Metz wrote:
> > > Hi all,
> > >
> > > GRASS needs some adjustments in order to be compatible with PROJ 6 +
GDAL
> > > 2.5
> > >
> > > The plain text file "share/proj/epsg" no longer exists. This file is
> > > currently required by the GUI location wizard to retrieve a list of
known
> > > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ
function
> > > proj_get_codes_from_database(). I suggest to enhance g.proj with a new
> > > option "list_codes_auth" which will print a list of codes for the
given
> > > autority name (EPSG, IGNF, etc.). This option can be made backwards
> > > compatible to read "share/proj/epsg" with PROJ versions up to 5. The
> > > location wizard can then use this new output of g.proj to construct a
list
> > > of known EPSG codes.
> >
> > If you want to do a nice GUI, proj_get_crs_info_list_from_database() is
an
> > enhanced version of proj_get_codes_from_database(), that will retrieve
> > more information besides the code: name, area of use, type of CRS
(geographic,
> > projected, compound, etc...)
> > in a very fast way (you can do the same with
proj_get_codes_from_database(),
> > and constructing a CRS for each code, but this is slower)
>
> Thanks for the hint!
>
> I have added a new option list_codes to g.proj that will print codes,
names, and proj definitions for the given authority in trunk r74174. This
new option works with PROJ 4, 5, and 6.

Unfortunately it does not work yet with PROJ 4 because new fns have been
added to the old proj_api.h...

Markus M

>
> The GUI is now (r74175) no longer reading the file share/proj/epsg which
no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get
the list of EPSG codes. This is important e.g. for the location wizard to
provide a list of known EPSG codes.
>
> The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not
compatible with PROJ 6.
>
> There are other authorities besides EPSG, these are supported with g.proj
list_codes= if compiled against PROJ 6. Maybe we should support them too.
>
> I will look at the issues mentioned below in the next few days, should
not be too much work I hope.
>
> Markus M
> >
> > >
> > > We need to take care of axis order if a CRS is created from EPSG
because
> > > the axis order can now be northing, easting instead of traditional
easting,
> > > northing. Maybe it is enough to enforce +axis=enu,
> >
> > You can only use this if you use a PROJ string when invokating
> > proj_create_crs_to_crs(), and this is the default axis order for PROJ
string anyway.
> >
> > > or to use GDAL's
> > > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)
> >
> > Yes, if you use GDAL OGRSpatialReference this is the way to go.
> >
> > If you don't use GDAL SRS and just PROJ API, you might also just reuse
> >
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298
> >
> > which is called for the source and target CRS of the PJ object created
> > with proj_create_crs_to_crs()
> >
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357
> >
> > Even
> >
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Broken: GRASS-GIS/grass-ci#3312 (master - d76f9f9)

2019-03-07 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #3312
Status: Broken

Duration: 18 mins and 22 secs
Commit: d76f9f9 (master)
Author: Markus Metz
Message: wxGUI: use g.proj list_codes=EPSG to read EPSG codes

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/02c3e255e837...d76f9f911d80

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/503176224?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] Broken: GRASS-GIS/grass-ci#3311 (master - 02c3e25)

2019-03-07 Thread Travis CI 
Build Update for GRASS-GIS/grass-ci
-

Build: #3311
Status: Broken

Duration: 14 mins and 52 secs
Commit: 02c3e25 (master)
Author: Markus Metz
Message: g.proj: +list_codes to list codes for given authority, compatible with 
PROJ 4, 5, 6

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

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/a3ed9a677b88...02c3e255e837

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/503174240?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 + PROJ 6 + GDAL 2.5

2019-03-07 Thread Markus Metz 
On Mon, Feb 25, 2019 at 9:42 PM Even Rouault 
wrote:
>
> On lundi 25 février 2019 15:10:10 CET Markus Metz wrote:
> > Hi all,
> >
> > GRASS needs some adjustments in order to be compatible with PROJ 6 +
GDAL
> > 2.5
> >
> > The plain text file "share/proj/epsg" no longer exists. This file is
> > currently required by the GUI location wizard to retrieve a list of
known
> > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function
> > proj_get_codes_from_database(). I suggest to enhance g.proj with a new
> > option "list_codes_auth" which will print a list of codes for the given
> > autority name (EPSG, IGNF, etc.). This option can be made backwards
> > compatible to read "share/proj/epsg" with PROJ versions up to 5. The
> > location wizard can then use this new output of g.proj to construct a
list
> > of known EPSG codes.
>
> If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an
> enhanced version of proj_get_codes_from_database(), that will retrieve
> more information besides the code: name, area of use, type of CRS
(geographic,
> projected, compound, etc...)
> in a very fast way (you can do the same with
proj_get_codes_from_database(),
> and constructing a CRS for each code, but this is slower)

Thanks for the hint!

I have added a new option list_codes to g.proj that will print codes,
names, and proj definitions for the given authority in trunk r74174. This
new option works with PROJ 4, 5, and 6.

The GUI is now (r74175) no longer reading the file share/proj/epsg which no
longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get the
list of EPSG codes. This is important e.g. for the location wizard to
provide a list of known EPSG codes.

The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not
compatible with PROJ 6.

There are other authorities besides EPSG, these are supported with g.proj
list_codes= if compiled against PROJ 6. Maybe we should support them too.

I will look at the issues mentioned below in the next few days, should not
be too much work I hope.

Markus M
>
> >
> > We need to take care of axis order if a CRS is created from EPSG because
> > the axis order can now be northing, easting instead of traditional
easting,
> > northing. Maybe it is enough to enforce +axis=enu,
>
> You can only use this if you use a PROJ string when invokating
> proj_create_crs_to_crs(), and this is the default axis order for PROJ
string anyway.
>
> > or to use GDAL's
> > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)
>
> Yes, if you use GDAL OGRSpatialReference this is the way to go.
>
> If you don't use GDAL SRS and just PROJ API, you might also just reuse
>
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298
>
> which is called for the source and target CRS of the PJ object created
> with proj_create_crs_to_crs()
>
https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
___
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

2019-03-07 Thread 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):

 Replying to [comment:4 sbl]:
 > To my knowledge, most of the tests that are currently failing, started
 failing due to fundamental changes from the introduction of Python 3, e.g.
 everything related to bytes vs. strings...

 If you scroll down far enough
 [http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
 here] there is this graph:

 
[[Image(http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/files_successful_plot.png)]]

 Last September, indeed, there was a spike of failing tests but still ~10%
 of the tests were practically always failing.

 That being said, supporting both Python 2 and 3 is a requirement
 encountered primarily in libraries, not applications. Applications usually
 only need to support a single Python version. GRASS does provide an API,
 but, at least from where I stand, it is primarily an application.
 Nevertheless, the decision that GRASS 7.8 will support both Python 2 and 3
 has been made and unless it is revoked, the code needs to support both
 versions.

 Nowadays, there is a great deal of experience in the Python community WRT
 both porting code from Python 2 to 3 and to supporting both Python
 versions from a single codebase. The latter usually involves using
 projects like [https://pypi.org/project/six/] and/or [https://python-
 future.org/]. Using them is of course not mandatory. Most projects only
 need a small part of their functionality, so they can often get away with
 just a [{{compat.py}}} module and appropriate imports. On projects of
 significant complexity though, it is often a good idea to use them.

 Long story short, it is indeed more difficult to maintain a cross-version
 compatible codebase but with some concessions it is an achievable goal.

 In my humble view, the fact that the tests are failing doesn't have to do
 with with Python 2 or Python 3 or even with the cross-version
 compatibility. There are two rules that are pretty much unanimously
 accepted in the software development industry:

 1. Don't break the build.
 2. You break the build, you fix it.

 (obviously, running the tests is considered part of the build)

 The afore-mentioned graph shows that GRASS devs don't run the tests as
 part of their development routine. I argue that this needs to change.
 Arguably, no one wants to wait for a long running testsuite to finish. And
 that's absolutely natural. Honestly speaking, no one ''should'' have to
 wait. That's what CI is for. To build the code and run the tests.

 The gist of the issue here is supporting GRASS' growth. Automated builds
 and improved testing procedures  are a prerequisite of this goal. An
 important checkpoint in this effort is achieving a green build.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] another grass python library question

2019-03-07 Thread Michael Barton 
Could try. I found another way, after trying several that didn't work.

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 7, 2019, at 2:22 PM, Stefan Blumentrath 
mailto:stefan.blumentr...@nina.no>> wrote:

What about:
grass.run_command('g.copy ', raster='{},{}'.format(variable, 'mapname')

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

Re: [GRASS-dev] another grass python library question

2019-03-07 Thread Stefan Blumentrath 
What about:
grass.run_command('g.copy ', raster='{},{}'.format(variable, 'mapname')










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

[GRASS-dev] another grass python library question

2019-03-07 Thread Michael Barton 
Here is another issue with an infurating problem of parameter pairs.

I have input map names saved to a set of variables.
I want to do the following:

grass.run_command('g.copy ', raster=[variable],[mapname])

The output [mapname] can be a string for a mapname or a previously defined 
variable containing the mapname.

I've looked at the docs for the scripting and python libraries and nothing 
there helps. I consistently get a file not found error or  a syntax error if I 
try to use string substitution.


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















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

Re: [GRASS-dev] [GRASS GIS] #3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are failing

2019-03-07 Thread GRASS GIS 
#3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are
failing
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by veroandreo):

 duplicate of #3706 ?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] syntax error for r.rescale

2019-03-07 Thread Michael Barton 
Found it. Need to use from_ (with underscore) instead of "from"

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 7, 2019, at 12:18 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:

I think this is because "from" is a Python keyword. But how to get around this 
when trying to include r.rescale in a script?

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 7, 2019, at 12:10 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:

Can anyone tell me why this raises a syntax error at the from argument?

grass.run_command('r.rescale', input=mis1, output=mis1_8bit, from='0,2048', 
to='0,255')

when

 r.rescale input=name [from=min,max] output=name to=min,max
   [title=phrase] [--overwrite] [--help] [--verbose] [--quiet] [--ui]

(GRASS 7.6.0)

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

















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

Re: [GRASS-dev] syntax error for r.rescale

2019-03-07 Thread Stefan Blumentrath 
> I think this is because "from" is a Python keyword. But how to get around 
> this when trying to include r.rescale in a script?

Did you try from_ ?

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

Re: [GRASS-dev] syntax error for r.rescale

2019-03-07 Thread Michael Barton 
I think this is because "from" is a Python keyword. But how to get around this 
when trying to include r.rescale in a script?

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 7, 2019, at 12:10 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:

Can anyone tell me why this raises a syntax error at the from argument?

grass.run_command('r.rescale', input=mis1, output=mis1_8bit, from='0,2048', 
to='0,255')

when

 r.rescale input=name [from=min,max] output=name to=min,max
   [title=phrase] [--overwrite] [--help] [--verbose] [--quiet] [--ui]

(GRASS 7.6.0)

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
















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

[GRASS-dev] syntax error for r.rescale

2019-03-07 Thread Michael Barton 
Can anyone tell me why this raises a syntax error at the from argument?

grass.run_command('r.rescale', input=mis1, output=mis1_8bit, from='0,2048', 
to='0,255')

when

 r.rescale input=name [from=min,max] output=name to=min,max
   [title=phrase] [--overwrite] [--help] [--verbose] [--quiet] [--ui]

(GRASS 7.6.0)

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















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

Re: [GRASS-dev] [GRASS GIS] #3772: Make the grass library importable outside of a GRASS session

2019-03-07 Thread GRASS GIS 
#3772: Make the grass library importable outside of a GRASS session
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by Nikos Alexandris):

 Making the `grass` library importable, will be of great. Imagine an HPC
 infrastructure set up in a way that allows for arbitrary Python code
 execution only. Albeit in a secure way. Having GRASS GIS importable, would
 fit such a case very well.

-- 
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] #3785: Gtk critical as soon as Grass starts - Grass crashes with 3d raster view

2019-03-07 Thread GRASS GIS 
#3785: Gtk critical as soon as Grass starts - Grass crashes with 3d raster view
+-
 Reporter:  virtuale71  |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:
Component:  Default |Version:  svn-releasebranch76
 Keywords:  |CPU:  x86-64
 Platform:  Linux   |
+-
 GRASS 7.6.0 (Eu):~ >
 (wxgui.py:2575): Gtk-CRITICAL **: 10:05:20.720: gtk_box_gadget_distribute:
 assertion 'size >= 0' failed in GtkCheckButton

 This appears as soon as Grass is launched. I can work with rasters but as
 soon as I swich to 3d Grass crashes.

-- 
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] #3771: Run tests on Travis

2019-03-07 Thread 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 sbl):

 Replying to [comment:3 pmav99]:
 > Running tests on CI doesn't really make sense if you have failing tests:
 http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

 To my knowledge, most of the tests that are currently failing, started
 failing due to fundamental changes from the introduction of Python 3, e.g.
 everything related to bytes vs. strings...

 So we would have to sort out those from tests that are failing for other
 reasons...

 > So the next step would be to make the tests pass.
 In general +1, but again, lets try to distinguish Pythen 3 related test
 failure from all others...
 Currently, somehow, most failing tests tell us how far we are from Python
 3 (and 2) support...

-- 
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] #3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are failing

2019-03-07 Thread GRASS GIS 
#3784: temporal: regression since 2019-02-22. Allmost all the temporal tests are
failing
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 [[Image(https://i.imgur.com/RboxuJm.png)]]

 source:
 http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

-- 
Ticket URL: 
GRASS GIS 

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