date:20160123

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by martinl):

 The programs crashes at source:grass/trunk/lib/driver/font.c#L151

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  major|  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by martinl):

 Hopefully fixed in r67630. Will check next build.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+
Changes (by martinl):

 * cc: grass-dev@… (added)
 * status:  new => assigned
 * owner:  grass-dev@… => martinl
 * priority:  major => blocker


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by hellik):

 Replying to [comment:10 martinl]:
 > Hopefully fixed in r67630. Will check next build.

 tested here locally by copying

 {{{
 C:\OSGeo4W\etc\fonts\fonts.conf
 }}}

 to

 {{{
 C:\OSGeo4W64\apps\grass\grass-7.0.3RC1\etc
 }}}

 and by adding

 {{{
 set FONTCONFIG_FILE=%GISBASE%\etc\fonts.conf
 }}}

 in the winGRASS windows console.

 {{{
 C:\>d.fontlist -l
 Unable to update the static FcBlanks: 0x0600
 Unable to update the static FcBlanks: 0x0601
 Unable to update the static FcBlanks: 0x0602
 Unable to update the static FcBlanks: 0x0603
 Unable to update the static FcBlanks: 0x06dd
 Unable to update the static FcBlanks: 0x070f
 Unable to update the static FcBlanks: 0x2028
 Unable to update the static FcBlanks: 0x2029
 Unable to update the static FcBlanks: 0xfff9
 Unable to update the static FcBlanks: 0xfffa
 Unable to update the static FcBlanks: 0xfffb
 cyrilc
 gothgbt
 gothgrt
 gothitt
 greekc
 greekcs
 greekp
 greeks
 italicc
 italiccs
 italict
 romanc
 romancs
 romand
 romans
 romant
 scriptc
 scripts
 AGENCYB
 [...]
 }}}

 basically it seems to work, though some error messages.

 so let's test next build.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by hellik):

 Replying to [comment:13 martinl]:
 > Replying to [comment:12 hellik]:
 > > basically it seems to work, though some error messages.
 > >
 > > so let's test next build.
 >
 > Please try the last build (no.53 64bit or no.216 32bit). Do you still
 see error messages?

 tested with

 {{{
 System Info
 GRASS version: 7.1.svn
 GRASS SVN revision: 67634
 Build date: 2016-01-23
 Build platform: x86_64-w64-mingw32
 GDAL: 1.11.3
 PROJ.4: 4.9.2
 GEOS: 3.5.0
 SQLite: 3.7.17
 Python: 2.7.5
 wxPython: 2.8.12.1
 Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
 }}}

 {{{
 C:\>d.fontlist -l
 cyrilc
 gothgbt
 gothgrt
 gothitt
 greekc
 greekcs
 greekp
 greeks
 italicc
 italiccs
 italict
 romanc
 romancs
 romand
 romans
 romant
 scriptc
 scripts
 AGENCYB
 AGENCYR
 ahronbd
 [...]
 }}}

 d.fontlist and change preferences within wxGUI works now. ready for
 backporting.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-
Changes (by wenzeslaus):

 * Attachment "run_grass.py" added.

 First prototype of API for simplified GRASS startup of standalone scripts

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by martinl):

 Replying to [comment:14 hellik]:
 > d.fontlist and change preferences within wxGUI works now. ready for
 backporting.

 good, done in r67642. Let's test the next grass70 build.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
 Reporter:  wenzeslaus   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  major|  Milestone:  7.1.0
Component:  Python   |Version:  svn-trunk
 Keywords:  startup, installation, scripts,  |CPU:  Unspecified
  interpreter, windows installer, pygrass,   |
  temporal, bootstrap, boilerplate   |
 Platform:  All  |
-+-
 To use GRASS GIS functionality in Python from outside of a GRASS session,
 i.e. without starting GRASS GIS explicitly and running a script (or an
 actual module) in the session, one needs to include approximately 50 lines
 as described in the
 [https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-
 script.setup grass.script.setup] manual (or in the lengthy related
 
[https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
 wiki page]).

 Ideally, one would just do import and then one or two lines of
 initialization, for example:

 {{{
 #!python
 import grass.script as gscript
 rcfile = gscript.init_data("~/grassdata", "nc_spm", "user1")
 do_what_ever_with_grass()
 os.remove(rcfile)
 }}}

 == Suggestion ==

 The attached code is a prototype implementation of the Python part which
 would allow something like this. The code can only work if the following
 variables are set:

 {{{
 #!bash
 export GRASS_EXECUTABLE="/path/to/grass"
 export LD_LIBRARY_PATH=$($GRASS_EXECUTABLE --config path)/lib
 export PYTHONPATH=$($GRASS_EXECUTABLE --config path)/etc/python
 }}}

 The `GRASS_EXECUTABLE` does not have to be set if `grass` is on the path
 or, in theory, if it is in on some standard path (e.g. `C:\Program Files
 (x86)\GRASS GIS 7.0.0\grass70.bat` on MS Windows). However, dynamic
 library path must always be set ahead (as described in #2424) for ctypes
 to work (both PyGRASS and temporal depends on ctypes). The path to Python
 packages must be set ahead as well if you want to use the initialization
 functions from the package.

 == Making it simple ==

 The three lines above might be good enough on Linux where you just dump it
 to command line or `.bashrc` but for MS Windows users it is too
 complicated. The QGIS project also considers this too much work
 ([https://github.com/qgis/qgis3.0_api/issues/9 PyQGIS bootstrap is
 complicated]).

 GRASS Python packages could go to the system packages directory, so that
 we avoid the need for setting `PYTHONPATH`. This might work well on MS
 Windows when usage of system Python is implemented as described in #2333.

 On Linux, `LD_LIBRARY_PATH` can be avoided if the libraries are installed
 into the system path. On MS Windows, putting more things on `PATH` is
 standard procedure from what I have seen. Mac OS X, `DYLD_LIBRARY_PATH`
 can't be used anyway [https://lists.osgeo.org/pipermail/grass-
 dev/2016-January/078531.html since El Capitan].

 GRASS GIS executable should be on path on all platforms in the same way as
 it is on path in Linux. This is maybe not standard on MS Windows but at
 the end this is what users want (they want GRASS to be available right
 away).


 == Challenges ==

 When putting dynamic libraries and Python packages directly into system
 paths, installing more than one GRASS version becomes more complicated.
 However, that's OK because only advanced users would have more than one
 version, so the hard work of making it work (perhaps just not using the
 default settings in the installer) will be on them. Beginners will likely
 have just one version. The exception might be on MS Windows where it is
 possible that beginner has standalone GRASS GIS, the one from QGIS and one
 from OSGeo4W.

 GRASS Python packages are not prepared to be imported when `GISBASE` is
 not set and may require even more. We would need to change the code to not
 require anything from GRASS session at import time. So far, I needed to
 add lazy initialization for the translate function (underscore) to be able
 to import `grass.script.core` (patch attached).

 There is already some duplication between `grass.script.setup` and
 `grass.py` executable. To create a full session (e.g. Mapset locking) we
 would need even more duplication. We could move some parts from `grass.py`
 to `grass.script.setup` if we are sure that we can import the right
 `grass.script.setup` during the initialization phase (we already rely on
 in when creating a Location).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-
Changes (by wenzeslaus):

 * Attachment "lazy_gettext.patch" added.

 Patch for the lazy initialization of the underscore function (does not
 require GISBASE at import time)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-

Comment (by hellik):

 Replying to [ticket:2873 wenzeslaus]:
 > To use GRASS GIS functionality in Python from outside of a GRASS
 session, i.e. without starting GRASS GIS explicitly and running a script
 (or an actual module) in the session, one needs to include approximately
 50 lines as described in the
 [https://grass.osgeo.org/grass70/manuals/libpython/script.html#module-
 script.setup grass.script.setup] manual (or in the lengthy related
 
[https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
 wiki page]).
 >
 > Ideally, one would just do import and then one or two lines of
 initialization, for example:
 >
 > {{{
 > #!python
 > import grass.script as gscript
 > rcfile = gscript.init_data("~/grassdata", "nc_spm", "user1")
 > do_what_ever_with_grass()
 > os.remove(rcfile)
 > }}}
 >
 > == Suggestion ==
 >
 > The attached code is a prototype implementation of the Python part which
 would allow something like this. The code can only work if the following
 variables are set:
 >
 > {{{
 > #!bash
 > export GRASS_EXECUTABLE="/path/to/grass"
 > export LD_LIBRARY_PATH=$($GRASS_EXECUTABLE --config path)/lib
 > export PYTHONPATH=$($GRASS_EXECUTABLE --config path)/etc/python
 > }}}
 >
 > The `GRASS_EXECUTABLE` does not have to be set if `grass` is on the path
 or, in theory, if it is in on some standard path (e.g. `C:\Program Files
 (x86)\GRASS GIS 7.0.0\grass70.bat` on MS Windows). However, dynamic
 library path must always be set ahead (as described in #2424) for ctypes
 to work (both PyGRASS and temporal depends on ctypes). The path to Python
 packages must be set ahead as well if you want to use the initialization
 functions from the package.
 >
 > == Making it simple ==
 >
 > The three lines above might be good enough on Linux where you just dump
 it to command line or `.bashrc` but for MS Windows users it is too
 complicated. The QGIS project also considers this too much work
 ([https://github.com/qgis/qgis3.0_api/issues/9 PyQGIS bootstrap is
 complicated]).
 >
 > GRASS Python packages could go to the system packages directory, so that
 we avoid the need for setting `PYTHONPATH`. This might work well on MS
 Windows when usage of system Python is implemented as described in #2333.

 there is no ''system Python'' in windows. users always has to install
 python manually systemwide, possibly interfering with other python
 installations installed by other software.

 >
 > On Linux, `LD_LIBRARY_PATH` can be avoided if the libraries are
 installed into the system path. On MS Windows, putting more things on
 `PATH` is standard procedure from what I have seen.
 >[...]
 >Mac OS X, `DYLD_LIBRARY_PATH` can't be used anyway
 [https://lists.osgeo.org/pipermail/grass-dev/2016-January/078531.html
 since El Capitan].
 >
 > GRASS GIS executable should be on path on all platforms in the same way
 as it is on path in Linux. This is maybe not standard on MS Windows but at
 the end this is what users want (they want GRASS to be available right
 away).

 IMHO it is not a good practice to put ''everything'' in ''%PATH%'' in
 windows. ''poisoning'' %PATH% should be avoided IMHO.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by annakrat):

 Thanks for working on this. Do we have an idea how did this bug happen? If
 yes, it would be good to have it documented here.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by martinl):

 Replying to [comment:12 hellik]:
 > basically it seems to work, though some error messages.
 >
 > so let's test next build.

 Please try the last build (no.53 64bit or no.216 32bit)

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

2016-01-23 Thread GRASS GIS

#2333: choose python interpreter during the GRASS installation on windows
-+-
  Reporter:  zarch   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  windows installer python
 |  interpreter
   CPU:  All |   Platform:  MSWindows 8
-+-

Comment (by hellik):

 Replying to [comment:24 annakrat]:
 > It seems Pietro got pretty close to solving this, any possibility we
 could restart the attempts? The patch may need a review by Helmut and then
 we can apply it to trunk? I would be glad to test it.

 the patch needs some review as the nsis-script changed a lot since then
 (e.g. 32bit/64bit, changes in env.bat, ...).

 there are some open questions:

 - should there in the standalone installer be only the option to choose
 the python interpreter or also some check of needed dependencies
 (wxwidgets, python win api etc.)? for example my system wide python
 installation (installed by another software) isn't compatible to run
 winGRASS out of the box

 - how/if should such an option implemented in OSGeo4W-winGRASS too? if
 not, there would be disparity between different platforms on windows
 (standalone, OSGeo4W, QGIS bundled). how should our users deal with these
 many different variants? e.g. for myself I never work with the standalone
 installer, prefer the OSGeo4W-environment as there are quite a lot tools,
 which can easily be updated.

 - ...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2860: The raster import gui adds layers to layer tree even if that option is deselected

2016-01-23 Thread GRASS GIS

#2860: The raster import gui adds layers to layer tree even if that option is
deselected
--+-
  Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  import
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by annakrat):

 * milestone:  7.0.3 => 7.0.4


Comment:

 Should be fixed in r67644. Keep it open until backport, I would wait for
 next release.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

2016-01-23 Thread GRASS GIS

#2333: choose python interpreter during the GRASS installation on windows
-+-
  Reporter:  zarch   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  windows installer python
 |  interpreter
   CPU:  All |   Platform:  MSWindows 8
-+-

Comment (by wenzeslaus):

 Replying to [comment:25 hellik]:
 > should there in the standalone installer be only the option to choose
 the python interpreter or also some check of needed dependencies
 (wxwidgets, python win api etc.)? for example my system wide python
 installation (installed by another software) isn't compatible to run
 winGRASS out of the box

 In [comment:52:ticket:580 ticket 580] Michael is saying that wxPython is
 bundled with GRASS GIS and the system Python is used. Is there a way to do
 something like this on Windows?

 > how/if should such an option implemented in OSGeo4W-winGRASS too?

 It would have to be implemented for the whole OSGeo4W I suppose. The
 reason for doing it there is the same as for the standalone version.
 OSGeo4W doesn't contain all the packages available through pip and it
 doesn't contain pip.

 > if not, there would be disparity between different platforms on windows
 (standalone, OSGeo4W, QGIS bundled).

 I think the idea is to make it more similar across operating system. On
 Linux, one does not have to install Python packages for GRASS separately
 or do some workaround to get the already installed there. Mac OS X works
 the same if you are (very) lucky.

 OSGeo4W, QGIS-bundled or whatever-bundled might need to use the internal
 Python option. Are the install scripts able to handle two options or it is
 too difficult?

 > how should our users deal with these many different variants? e.g. for
 myself I never work with the standalone installer, prefer the OSGeo4W-
 environment as there are quite a lot tools, which can easily be updated.

 There are already different variants. And unless all OSGeo projects agree
 on using OSGeo4W exclusively, we will always have them. With installation
 of additional packages, I'm not worried about them much. I'm more worried
 about them in regard to #2873, but still, Linux, Mac and standalone
 would/could be the same, OSGeo4W and QGIS-bundled would be different.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2874: r.external: add offset and num_digits as r.in.gdal

2016-01-23 Thread GRASS GIS

#2874: r.external: add offset and num_digits as r.in.gdal
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.4
 Component:  Raster   |Version:  svn-releasebranch70
Resolution:   |   Keywords:  r.external
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * keywords:   => r.external


Comment:

 * offset was implemented in r46429
  * num_digits in r66714

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

2016-01-23 Thread GRASS GIS

#2333: choose python interpreter during the GRASS installation on windows
-+-
  Reporter:  zarch   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  windows installer python
 |  interpreter
   CPU:  All |   Platform:  MSWindows 8
-+-

Comment (by wenzeslaus):

 Replying to [comment:27 hellik]:
 > as mentioned at other places, there is no system wide python in windows
 at all.  users has to do the install for themself, also all the packages

 Right. Python installed ahead which is on path, registry or whatever is
 appropriate - that's what I mean by system Python.

 > > It would have to be implemented for the whole OSGeo4W I suppose. The
 reason for doing it there is the same as for the standalone version.
 OSGeo4W doesn't contain all the packages available through pip and it
 doesn't contain pip.
 > >
 >
 > what about to improve the situation in the underlying Osgeo4w?

 Good approach. I guess this ticket would still apply standalone installer?

 > There are already some starting efforts regarding pip etc.

 Do you have some more info about it? Only thing I know is not really
 encouraging: [https://lists.osgeo.org/pipermail/osgeo4w-
 dev/2015-November/002965.html my question regarding pip from September
 2015] and [https://lists.osgeo.org/pipermail/osgeo4w-
 dev/2015-September/002957.html answer to it from November].

 Even if we ignore the issue that user have to remember to install every
 package twice (I guess common on MS Windows), this still doesn't solve the
 issue of using the same Python from a Python editor and GRASS or using
 GRASS and ArcGIS together (both being a common request).

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] hierarchical segmentation

2016-01-23 Thread Markus Neteler

On Fri, Jan 22, 2016 at 8:43 PM, Martin Landa  wrote:
> Hi,
>
> 2016-01-22 14:15 GMT+01:00 Martin Landa :
>>> but not yet in 7.0
>>
>> right, set_path() in relbr70 needs to be updated. I am putting it to
>> my hot TODOS. Ma
>
> done in r67626. Installing i.segment.hierarchical also works here now. Ma

Great Martin, now it compiles here as well in 7.0 on Fedora 23.

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by annakrat):

 Replying to [comment:17 martinl]:
 > GRASS OSGeo4W package since 7.0.3 doesn't depend on `msys` package.
 WinGRASS is built using completely fresh environment based on msys2 which
 is not shipped in osgeo4w framework. So the fontconfing file was just
 missing.

 Thanks for clarifying!

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

2016-01-23 Thread GRASS GIS

#2870: d.fontlist crashes on Windows
--+
  Reporter:  annakrat |  Owner:  martinl
  Type:  defect   | Status:  assigned
  Priority:  blocker  |  Milestone:  7.0.3
 Component:  Display  |Version:  svn-releasebranch70
Resolution:   |   Keywords:  d.fontlist, font, wingrass
   CPU:  Unspecified  |   Platform:  MSWindows 8
--+

Comment (by martinl):

 GRASS OSGeo4W package since 7.0.3 doesn't depend on `msys` package.
 WinGRASS is built using completely fresh environment based on msys2 which
 is not shipped in osgeo4w framework. So the fontconfing file was just
 missing.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-

Comment (by wenzeslaus):

 See also Glynn's comment in [comment:53:ticket:580 ticket 580] speaking
 about "fixing the installation process to make GRASS 'sessions' an
 optional feature".

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

2016-01-23 Thread GRASS GIS

#2333: choose python interpreter during the GRASS installation on windows
-+-
  Reporter:  zarch   |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  normal  |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  windows installer python
 |  interpreter
   CPU:  All |   Platform:  MSWindows 8
-+-

Comment (by hellik):

 Replying to [comment:26 wenzeslaus]:
 > Replying to [comment:25 hellik]:
 > > should there in the standalone installer be only the option to choose
 the python interpreter or also some check of needed dependencies
 (wxwidgets, python win api etc.)? for example my system wide python
 installation (installed by another software) isn't compatible to run
 winGRASS out of the box
 >
 > In [comment:52:ticket:580 ticket 580] Michael is saying that wxPython is
 bundled with GRASS GIS and the system Python is used. Is there a way to do
 something like this on Windows?

 as mentioned at other places, there is no system wide python in windows at
 all.  users has to do the install for themself, also all the packages

 >
 > > how/if should such an option implemented in OSGeo4W-winGRASS too?
 >
 > It would have to be implemented for the whole OSGeo4W I suppose. The
 reason for doing it there is the same as for the standalone version.
 OSGeo4W doesn't contain all the packages available through pip and it
 doesn't contain pip.
 >

 what about to improve the situation in the underlying Osgeo4w? There are
 already some starting efforts regarding pip etc.

 > > if not, there would be disparity between different platforms on
 windows (standalone, OSGeo4W, QGIS bundled).
 >
 > I think the idea is to make it more similar across operating system. On
 Linux, one does not have to install Python packages for GRASS separately
 or do some workaround to get the already installed there. Mac OS X works
 the same if you are (very) lucky.
 >
 > OSGeo4W, QGIS-bundled or whatever-bundled might need to use the internal
 Python option. Are the install scripts able to handle two options or it is
 too difficult?
 >
 > > how should our users deal with these many different variants? e.g. for
 myself I never work with the standalone installer, prefer the OSGeo4W-
 environment as there are quite a lot tools, which can easily be updated.
 >
 > There are already different variants. And unless all OSGeo projects
 agree on using OSGeo4W exclusively, we will always have them. With
 installation of additional packages, I'm not worried about them much. I'm
 more worried about them in regard to #2873, but still, Linux, Mac and
 standalone would/could be the same, OSGeo4W and QGIS-bundled would be
 different.

 I'm not quite sure about the effort regarding overcome the differences of
 OS at software  level. but that's a personal point of view. If you look at
 the QGIS ticket at using "system wide python". there is at least some
 concern at the windows site of life.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-

Comment (by wenzeslaus):

 Replying to [comment:1 hellik]:
 > Replying to [ticket:2873 wenzeslaus]:
 > > GRASS Python packages could go to the system packages directory, so
 that we avoid the need for setting `PYTHONPATH`. This might work well on
 MS Windows when usage of system Python is implemented as described in
 #2333.
 >
 > there is no ''system Python'' in windows. users always has to install
 python manually systemwide, possibly interfering with other python
 installations installed by other software.

 By system Python I mostly mean what #2333 is talking about. Possible
 interference is the inherent issue of Windows operating system. I'm OK
 with including multiple options in the installer giving the choice to the
 user (with the last option being "Don't know what to choose? Install
 Ubuntu and let the package managers solve it for you." ;-).

 > > On MS Windows, putting more things on `PATH` is standard procedure
 from what I have seen...
 > > GRASS GIS executable should be on path on all platforms in the same
 way as it is on path in Linux. This is maybe not standard on MS Windows
 but at the end this is what users want (they want GRASS to be available
 right away).
 >
 > IMHO it is not a good practice to put ''everything'' in ''%PATH%'' in
 windows. ''poisoning'' %PATH% should be avoided IMHO.

 I'm not sure if we can do it. Is there a another way how to set path to
 dynamic libraries for a process (so that Python scripts using GRASS ctypes
 work)?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-
Changes (by wenzeslaus):

 * Attachment "lib_python_script_init_data.patch" added.

 Second prototype of API for simplified GRASS startup of standalone scripts
 as a patch for lib/python/script

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-

Comment (by wenzeslaus):

 I uploaded a second prototype of the API as a patch. Before executing the
 code outside of GRASS GIS, the following is needed:

 {{{
 #!bash
 export GRASS_EXECUTABLE="/path/to/grass"  # if GRASS is not on path
 export LD_LIBRARY_PATH=$($GRASS_EXECUTABLE --config path)/lib
 export PYTHONPATH=$($GRASS_EXECUTABLE --config path)/etc/python
 }}}

 The minimal script is:

 {{{
 #!python
 import grass.script as gscript
 import grass.script.setup as gsetup
 session = gsetup.init_data("~/grassdata", "nc_spm", "user1")
 # code goes here, e.g. gscript.run_command(...)
 session.close()
 }}}

 The names and the overall API is not final, nor is the implementation and
 it might be nicer to have one import instead two. However, I think the
 basic structure is right. Please comment.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

2016-01-23 Thread GRASS GIS

#2873: Simplify usage of GRASS in Python from outside
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.1.0
 Component:  Python  |Version:  svn-trunk
Resolution:  |   Keywords:  startup, installation, scripts,
 |  interpreter, windows installer, pygrass,
   CPU:  |  temporal, bootstrap, boilerplate
  Unspecified|   Platform:  All
-+-
Changes (by wenzeslaus):

 * Attachment "test_no_session.py" added.

 Test code for thge second prototype of API

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

[GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

Re: [GRASS-dev] [GRASS GIS] #2860: The raster import gui adds layers to layer tree even if that option is deselected

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

Re: [GRASS-dev] [GRASS GIS] #2874: r.external: add offset and num_digits as r.in.gdal

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

Re: [GRASS-dev] hierarchical segmentation

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2870: d.fontlist crashes on Windows

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2333: choose python interpreter during the GRASS installation on windows

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

Re: [GRASS-dev] [GRASS GIS] #2873: Simplify usage of GRASS in Python from outside

26 matches

Site Navigation

Mail list logo

Footer information