[GRASS-dev] [GRASS GIS] #3457: v.what test broken

[GRASS GIS]

#3457: v.what test broken
---+-
 Reporter:  annakrat   |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  blocker|  Milestone:  7.4.0
Component:  Vector |Version:  svn-trunk
 Keywords:  v.what, tests  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 v.what test was broken in r70700:

 
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2017-03-01-08-00/report_for_nc_basic_spm_grass7_nc/vector/v.what/test_vwhat_ncspm/index.html

 Looking at the test results, v.what seems to actually give wrong results.
 Note that developers are expected to at least run the existing tests
 (ideally write new test) before submitting such changes.

--
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] #3456: Trunk fails to compile on Xenial

[GRASS GIS]

#3456: Trunk fails to compile on Xenial
--+-
  Reporter:  marisn   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.4.0
 Component:  Compiling|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [ticket:3456 marisn]:
 > Ubuntu Xenial ships with GDAL 1.11.3, released 2015/09/16. It seems that
 trunk (most likely 7.4 too) needs a more recent GDAL version, still it
 fails to detect it during configuration phase.
 > Either compatibility with GDAL 1.11 must be restored (v.out.ogr) or
 configure should fail with an error of incompatible GDAL version.

 Compatibility of v.out.ogr with GDAL 1.11 has been restored in trunk
 r71854. Relbr74 is not affected.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python 3 porting and unicode

[Laurent C.]

Hi Vaclav,

I think that it would make much more sense to have the GRASS python
libraries using unicode, and to add an interface managing the
translation to/from bytes when dealing with C code.
Python programmers using the GRASS libraries will expect unicode strings.

Laurent


2017-11-26 21:21 GMT-06:00 Vaclav Petras :
> Dear all,
>
> after looking at different Python 2 to 3 porting issues, doing r71849, and
> reading #3392, I understand the following:
>
> * Several solutions for poring exist. Most recent one is python-future
> project, but only from __future__ import ... is part of the library and thus
> guaranteed with recent Python 2.7. (We can discuss concrete steps
> separately.)
>
> * However, the most challenging part of the porting will be the unicode.
>
> * There is no way around the unicode when using Python 3. Unicode is
> inherent part of the language even things such as os.environ or
> sys.stdout.write() work only with unicode. I'm not sure what exactly the
> rule is here, but it seems to be everywhere.
>
> * I haven't seen any simple fix which would limit the changes in the code in
> a way, e.g., in which print statement can be fixed.
>
> * GUI will always use unicode because that's how the libraries and
> interfaces as set.
>
> * In relation to the previous point, one of the reasons why unicode is used
> that thinks like text[:10] actually return 10 characters to display.
>
> * C library will not use unicode for now.
>
> * Users of the Python API who are using Python 3 will expect unicode strings
> to work, i.e. expect run_command('g.region', flags='p') to work (not just
> run_command(b'g.region', flags=b'p')).
>
> * If Python libraries are unicode, there will need to be an interface to
> work with ctypes which would add to existing code for transferring from C
> world to Python and back.
>
> * If Python libraries are bytes, there will need to be an interface to work
> with GUI in unicode as well as with users of the API who will expect unicode
> to work. In other words, internally it would use bytes, but interface must
> be both bytes (for modules and internal use) and unicode (for GUI and
> users).
>
> * Having unicode-based library means encoding and decoding on any "external"
> interface such as file reading or ctypes.
>
> * Having bytes-based library means encoding and decoding on any interface
> such as Python 3 interface such as os.environ and additionally rewriting all
> string literals ("abc") to bytes (b"abc").
>
> * It seems hard to predict when we will know the right encoding of the text.
> It seems that we will need it with any solution since garbage-in-garbage
> stops when you need to use some system interface function in Python 3 which
> requires unicode. Although e.g. sys.stdout.write() has a (less generic)
> sys.stdout.buffer.write() alternative, os.environb does not work on MS
> Windows.
>
> An example fix in r71849 is done using a (custom) decode function which
> creates unicode (standard string in Python3) when file content is read.
> Alternative to this change would be changing all the strings in the file to
> bytes (b'abc' as opposed to 'abc').
>
> Please comment or link other related discussions.
>
> Thanks,
> Vaclav
>
>
> python3 -c "import os; os.environ[b'abc'] = b'def'"
> python3 -c "import os; os.environb[b'abc'] = b'def'"
> python3 -c "import sys; sys.stdout.write(b'abc\n')"
> python3 -c "import sys; sys.stdout.buffer.write(b'abc\n')"
> python3 -c "import os; print(type(os.name))"
> https://trac.osgeo.org/grass/changeset/71849
> https://trac.osgeo.org/grass/ticket/2708
> https://trac.osgeo.org/grass/ticket/3392
> https://trac.osgeo.org/grass/query?status=!closed=~python3
> https://trac.osgeo.org/grass/query?status=!closed=~encoding
> https://trac.osgeo.org/grass/query?status=!closed=~unicode
>
> ___
> 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

[GRASS-dev] [GRASS GIS] #3456: Trunk fails to compile on Xenial

[GRASS GIS]

#3456: Trunk fails to compile on Xenial
-+-
 Reporter:  marisn   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  major|  Milestone:  7.4.0
Component:  Compiling|Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Ubuntu Xenial ships with GDAL 1.11.3, released 2015/09/16. It seems that
 trunk (most likely 7.4 too) needs a more recent GDAL version, still it
 fails to detect it during configuration phase.
 Either compatibility with GDAL 1.11 must be restored (v.out.ogr) or
 configure should fail with an error of incompatible GDAL version.
 {{{
 gcc  -g -O2   -I/home/marisn/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/include -I/home/marisn/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/include   -I/usr/include/gdal -I/usr/include -DPACKAGE=\""grassmods"\"
 -I/usr/include/gdal -I/home/marisn/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/include -I/home/marisn/soft/grass_trunk/dist.x86_64-pc-linux-
 gnu/include -DRELDIR=\"vector/v.out.ogr\" -o OBJ.x86_64-pc-linux-
 gnu/main.o -c main.c
 main.c: In function ‘main’:
 main.c:473:49: error: ‘Ogr_driver’ undeclared (first use in this function)
   G_debug(2, "driver %d : %s", i, OGR_Dr_GetName(Ogr_driver));
 }}}

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GRASS community at BiDS 2017 ?

[Moritz Lennert]

Hi,

Is anyone else from the GRASS community attending the Big Data from Space 
(BiDS) 2017 conference that starts tomorrow in Toulouse ?

I'm on my way there and will stay until Friday morning.

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

Re: [GRASS-dev] [GRASS GIS] #3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon

[GRASS GIS]

#3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon
--+-
  Reporter:  bcbernardo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  7.2.1
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-

Comment (by martinl):

 Replying to [ticket:3455 bcbernardo]:
 > In GRASS GIS 7.2.1 (from the QGIS 2.18 suite), running on Windows 7 32
 bits SP1, installing any addon with g.extension returns:
 >
 {{{
 > Downloading precompiled GRASS Addons ...
 > "ERROR: Extension  not found"
 }}}

 it's not clear how do you run the command, from GRASS Plugin Shell? Anyway
 there is no 'extension.name' Addons, see (1)

 (1) https://grass.osgeo.org/grass72/manuals/addons/

--
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] #3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon

[GRASS GIS]

#3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon
--+-
  Reporter:  bcbernardo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  7.2.1
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  MSWindows 7
--+-
Changes (by hellik):

 * platform:  Unspecified => MSWindows 7
 * version:  unspecified => 7.2.1


--
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] #3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon

[GRASS GIS]

#3455: Grass 7.2.1 returns "Extension(...)not found" when installing addon
-+-
 Reporter:  bcbernardo   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 In GRASS GIS 7.2.1 (from the QGIS 2.18 suite), running on Windows 7 32
 bits SP1, installing any addon with g.extension returns:

 {{{
 Downloading precompiled GRASS Addons ...
 "ERROR: Extension  not found"
 }}}

 Running the module with verbose flag on adds the following line to result:

 {{{
 "Downloading source code for  from
 
 which is identified as 'remote_zip' type of source..."
 }}}

 I have been trying to perform these installations for a few days, with no
 results, in more than one computer at my workplace. Re-installing QGIS
 suite does not appear to make any difference. The company's policy on
 downloading and opening executable files will not allow me to install a
 GRASS GIS stand-alone. I do can download the zipfile manually from the
 wingrass http index, though, which makes me think it is not a matter of
 server availability (as reported
 [https://gis.stackexchange.com/questions/262210/grass-gis-addon-extension-
 not-found-could-the-problem-be-with-the-grass-addon elsewhere]) or
 internet access restrictions.

--
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] #3454: r.timestamp: Add option for copying timestamp(s) from other raster map(s)

[GRASS GIS]

#3454: r.timestamp: Add option for copying timestamp(s) from other raster map(s)
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  minor|  Milestone:  7.5.0
Component:  Raster   |Version:  svn-trunk
 Keywords:  r.timestamp  |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 It would be helpful if r.timestamp had an option to copy timestamp(s) from
 one or more raster maps.

 E.g. if one generates a vegetation Index or other artificial band from two
 image bands it would be handy to be able assign timestamp of the input
 band(s) to the result.
 Or when aggregating data over several maps / scenes, being able to use the
 "temporal bonding box" as a timestamp would be useful.

 r.info -e can get the timestamp of the source map so it can easily be
 assigned to the newly produced map. However, the latter case requires a
 bit more coding from the user.

--
Ticket URL: 
GRASS GIS 

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