Re: [GRASS-dev] verbose in grass.array .write() function

[Hamish]

> Johannes Radinger wrote:
> > in GRASS 6.5 the python array.write() function in
> > http://svn.osgeo.org/grass/grass/branches/develbranch_6/lib/python/array.py
> > has set verbose=TRUE. Is there any reason for that?

I guess you are talking about this:
  
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/array.py#L238


Glynn:
> It was probably added during development and not reverted.

just to note that verbose=True argument for r.in.bin is present in all
branches, and has been there for some years (for better or worse).


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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Markus Neteler]

On Sat, Apr 6, 2013 at 10:56 AM, Markus Neteler  wrote:
> Remains:
> lib/gs/plot.c:34: error: conflicting types for 'nearest'

... also solved using a fresh SVN extract.

The remaining errors are related to the outdated Python on that AIX 5.3 machine.

Next step is to check with AIX 7.1 which Ivan may do. I have updated the
Wiki page:

http://grasswiki.osgeo.org/wiki/Compile_and_Install#AIX
-> GRASS 7: Using the GNU gcc compiler:

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

[GRASS-dev] Using Trac wiki for documenting development during GSoC

[Vaclav Petras]

Hi all,

it would be better to announce and discuss this sooner but still I
hope that it will be considered for future work.

According to what was discussed during Community Sprint Genova [1],
the proposals and progress related to development during GSoC should
be held at the (GRASS) Trac Wiki. The GRASS Wiki should not be used to
this because it is intended to document existing features and
procedures not the development of features. So, the currently achieved
results of GSoC should be at GRASS Wiki.

Vaclav

[1] 
http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Genova_2013#Vaclav_Petras


== Examples of pages which are at GRASS Wiki and Trac Wiki (from wxGUI) ==

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/wxIClass
http://grasswiki.osgeo.org/wiki/WxIClass

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Modeler
http://grasswiki.osgeo.org/wiki/WxGUI_Modeler

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/GUIForPs.map
http://grasswiki.osgeo.org/wiki/WxGUI_Cartographic_Composer

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/vkrige


== Syntax ==

Unfortunately, Trac wiki uses different syntax than MediaWiki, so one
have to use both to properly document the work at Trac Wiki and GRASS
Wiki.

http://grasswiki.osgeo.org/wiki/Help:Editing
https://trac.osgeo.org/grass/wiki/WikiFormatting
https://trac.osgeo.org/grass/wiki/WikiRestructuredText


== Content ==

The GRASS Wiki:
* manual enhancement
* howtos for users (e.g., how to do classification)
* howtos for power users, testers and developers (e.g., how to compile)
* howtos for developers (e.g., grass python programming)
* ...

The (GRASS) Trac Wiki:
* collecting proposals
* how the development of some part is going
* notepad for developers


== The rule strength ==

Since it is not absolutely sure what should be where, it is not
required to follow this rule, it is only strongly recommended for new
pages.

For GSoC, it is even less clear because it would be better to be more
accessible, i.e use more known MediaWiki syntax at GRASS Wiki. But
maybe it is not so difficult to use both wikis.

For existing pages, some of the pages should be definitely moved,
especially those messy pages (or its parts) with many proposals should
be moved. However, manpower should not be wasted for the quick
migration, especially when it was some similar consideration but with
different result some time ago (all development related pages such as
compiling was about to move to Trac).


== Example pages with content which should be at Trac Wiki ==

http://grasswiki.osgeo.org/wiki/Toolboxes
http://grasswiki.osgeo.org/wiki/WxGUI#Direct_printing
http://grasswiki.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#General_GUI_Design
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] libgis: G_FATAL_EXIT|PRINT|RETURN

[Markus Metz]

On Sat, Apr 6, 2013 at 6:27 PM, Martin Landa  wrote:
> Hi,
>
> libgis defines
>
> /* error codes */
> #define G_FATAL_EXIT0
> #define G_FATAL_PRINT   1
> #define G_FATAL_RETURN  2
>
> These defines are used by a few functions, eg.
> G_check_input_output_name(). Other candidates could eg.
> Vect_open_old() and similar functions (eg. call G__error() when vector
> map is not found). I would suggest to add G__error() and
> G__set_error_code() just for internal use (see the attached path).

What's your motivation for adding G__error() and G__set_error_code()?
Are there problems with e.g. Vect_open_old()?

Markus M

>
> What do you think? Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1672: gcpmanager fails to list source mapsets if non-ascii characters in grass data dir path

[GRASS GIS]

#1672: gcpmanager fails to list source mapsets if non-ascii characters in grass
data dir path
--+-
 Reporter:  hamish|   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  normal|   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-trunk 
   
 Keywords:  georectifier, UnicodeDecodeError  |Platform:  Linux 
   
  Cpu:  x86-64|  
--+-
Changes (by torsti):

  * version:  6.4.2 => svn-trunk


Comment:

 This one is still around (r55643). It can be traced back to
 'self.grassdatabase' in '!OnLocation' (gui/wxpython/gcp/manager.py, line
 376), which gets its value at line 94:

 {{{
 self.grassdatabase = grass.gisenv()['GISDBASE']
 }}}

 'gisenv' is defined at line 720 in lib/python/script/core.py:
 {{{
 s = read_command("g.gisenv", flags='n')
 return parse_key_val(s)
 }}}

 Neither the string 's' read from g.gisenv nor the dictionary returned by
 'parse_key_val' is explicitly decoded to Unicode, so when it is finally
 implicitly cast to Unicode somewhere in Python's bowels, the default ascii
 codec is used, which leads to errors if $GISDBASE contains non ascii
 characters.

 This a wider python (at least for < 3.x) problem, and fixing it for this
 specific issue won't probably solve all existing !UnicodeDecodeErrors nor
 prevent new ones from surfacing, but at least any GUI component calling
 gisenv can probably be fixed at one location.

 Any filenames/paths read into wxpython/pygrass should probably be
 explicitly decoded to Unicode, e.g. with the 'decode()' function defined
 at line 79 in script/core.py. Enforcing only ascii chars works for mapset
 and location names, but can't/shouldn't be the solution for path
 components not under GRASS's direct control.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] libgis: G_FATAL_EXIT|PRINT|RETURN

[Martin Landa]

Hi,

libgis defines

/* error codes */
#define G_FATAL_EXIT0
#define G_FATAL_PRINT   1
#define G_FATAL_RETURN  2

These defines are used by a few functions, eg.
G_check_input_output_name(). Other candidates could eg.
Vect_open_old() and similar functions (eg. call G__error() when vector
map is not found). I would suggest to add G__error() and
G__set_error_code() just for internal use (see the attached path).

What do you think? Martin

--
Martin Landa  * http://geo.fsv.cvut.cz/~landa


libgis_err_code.diff
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1919: add anchors to documentation website (was: add achors to documentation website)

[GRASS GIS]

#1919: add anchors to documentation website
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  Website  
Component:  Website  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by neteler):

  * milestone:  7.0.0 => Website


Comment:

 We use CMSMS. Hence, a volunteer would need to study
 http://docs.cmsmadesimple.org/tags/core/cms_selflink
 and related extensions.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.fillnulls failure (grass7 )

[epi]

I used the --overwrite option

i had problems with r.fillnulls recently see : 
http://osgeo-org.1560.n6.nabble.com/r-fillnulls-error-lt-z-gt-is-not-a-valid-flag-grass7-td5034768.html
after that fix the same syntax was working


changing the output to a new name i got the same error

GRASS 7.0.svn (utm19N_wgs84):/home/epy > r.fillnulls input=dtm1 output=dtm1fill 
--overwrite
Using RST interpolation...
Locating and isolating NULL areas...
 100%
Growing NULL areas
Assigning IDs to NULL areas
 100%
Processing 1 map holes
Filling hole 2 of 1
 100%
 100%
 100%
Note: The following warnings about number of points for interpolation may
be ignored.
ERROR: Database connection not defined for layer 1
ERROR: Failed to fill hole 2
WARNING: Raster map  not found
WARNING:  nothing removed
GRASS 7.0.svn (utm19N_wgs84):/home/epy > 


Il giorno 06/apr/2013, alle ore 11:08, Markus Neteler  ha 
scritto:

> On Sat, Apr 6, 2013 at 4:25 PM, epi  wrote:
> ...
>> GRASS 7.0.svn (utm19N_wgs84):~ > r.fillnulls input=dtm1 output=dtm1
>> --overwrite
> 
> You try to overwrite the source with the target, to my knowledge invalid
> (sure, the module should say so).
> 
> Try
> r.fillnulls input=dtm1 output=dtm1_filled
> 
> Markus

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

Re: [GRASS-dev] r.fillnulls failure (grass7 )

[Markus Neteler]

On Sat, Apr 6, 2013 at 4:25 PM, epi  wrote:
...
> GRASS 7.0.svn (utm19N_wgs84):~ > r.fillnulls input=dtm1 output=dtm1
> --overwrite

You try to overwrite the source with the target, to my knowledge invalid
(sure, the module should say so).

Try
r.fillnulls input=dtm1 output=dtm1_filled

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

[GRASS-dev] r.fillnulls failure (grass7 )

[epi]

epy@epinux:~/dev/grass_trunk$ svn up
Updating '.':
At revision 55645.


GRASS 7.0.svn (utm19N_wgs84):~ > g.region rast=dtm1 -ap
projection: 1 (UTM)
zone:   19
datum:  wgs84
ellipsoid:  wgs84
north:  4720170
south:  4715050
west:   391340
east:   398580
nsres:  10
ewres:  10
rows:   512
cols:   724
cells:  370688

GRASS 7.0.svn (utm19N_wgs84):~ > r.fillnulls input=dtm1 output=dtm1 --overwrite

Using RST interpolation...
Locating and isolating NULL areas...
 100%
Growing NULL areas
Assigning IDs to NULL areas
 100%
Processing 1 map holes
Filling hole 2 of 1
 100%
 100%
 100%
Note: The following warnings about number of points for interpolation may
be ignored.
ERROR: Database connection not defined for layer 1
ERROR: Failed to fill hole 2
WARNING: Raster map  not found
WARNING:  nothing removed

GRASS 7.0.svn (utm19N_wgs84):~ > 



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

Re: [GRASS-dev] [GRASS GIS] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-

Comment(by epifanio):

 Annakrat that is correct, those examples are for embedding the IPython
 *kernel*, not UI.

 IMHO,  try to embed the notebbok is worth to try (much powerful and easier
 to implement than the standard IPython shell)
 in wx 2.9 a simple code like :

 {{{
 import wx
 import wx.html2

 app = wx.App(False)
 frame = wx.Frame(None, -1, 'A Simple Frame')
 browser = wx.html2.WebView.New(frame)
 browser.LoadURL("http://IP:PORT/NoetebookName.ipynb";)
 frame.Show()
 app.MainLoop()
 }}}

 will open a wx frame within the notebbok.
 # the problem here is wx2.9 ...

 We can have a "notebook dashboard" written in a WX frame as part of the
 grass wx gui, something like :


 {{{
 #!/usr/local/bin/python

 import sys

 import wx

 import wx.html2

 class MyFrame(wx.Frame):
 def __init__(self, parent, title):
 wx.Frame.__init__(self, parent, -1, title,
   pos=(150, 150), size=(350, 285))
 menuBar = wx.MenuBar()
 menu = wx.Menu()
 menu.Append(wx.ID_EXIT, "E&xit\tAlt-X", "Exit")
 menuBar.Append(menu, "&File")
 self.SetMenuBar(menuBar)
 self.CreateStatusBar()
 panel = wx.Panel(self)
 text = wx.StaticText(panel, -1, "Notebook Browser")
 text.SetFont(wx.Font(14, wx.SWISS, wx.NORMAL, wx.BOLD))
 text.SetSize(text.GetBestSize())

 NoetebookName_btn = wx.Button(panel, -1, "NoetebookName")
 self.Bind(wx.EVT_BUTTON, self.showBrowser, NoetebookName_btn)
 sizer = wx.BoxSizer(wx.VERTICAL)
 for ctrl in [text, browser_btn]:
 sizer.Add(ctrl, 0, wx.ALL, 10)
 panel.SetSizer(sizer)
 panel.Layout()

 def showBrowser(self, evt):
 app = wx.App(False)
 frame = wx.Frame(None, -1, 'A Simple Frame')
 browser = wx.html2.WebView.New(frame)
 browser.LoadURL("http://IP:PORT/NoetebookName.ipynb";)
 frame.Show()


 class MyApp(wx.App):
 def OnInit(self):
 frame = MyFrame(None, "Simple wxPython App")
 self.SetTopWindow(frame)
 frame.Show(True)
 return True

 if __name__ == '__main__':
 app = MyApp(redirect=False, clearSigInt=False)
 app.MainLoop()
 }}}

 Instead of a single button, we'll have (auto generated) buttons for each
 notebook avalable in the IPython notebook dir, and open a new tab in the
 wx-dashboard-frame when a button is pressed
 (notebook dir is in the ipython_notebook_config.py
 "c.FileNotebookManager.notebook_dir")

 Hope make sense ...
 if looking for an "ancient" wx-gui for ipython .. i found something here
 [https://code.google.com/p/editra-plugins/wiki/IPythonShellPlugin here]
 but is really old ...

-- 
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] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-
Changes (by timmie):

 * cc: timmie (added)


-- 
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] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-

Comment(by timmie):

 Ok, since this ticket here is closed, please follow up on the new
 enhancement ticket:

 use IPython for python Shell in wxGui if
 installedhttps://trac.osgeo.org/grass/ticket/1922

-- 
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] #1922: use IPython for python Shell in wxGui if installed

[GRASS GIS]

#1922: use IPython for python Shell in wxGui if installed
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 If a user has IPython installed, the more convenient and science ready
 IPython shell may be used as the Python Shell.

 See:
 https://trac.osgeo.org/grass/ticket/666#comment:7

-- 
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] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-

Comment(by timmie):

 Replying to [comment:9 annakrat]:
 > Replying to [comment:7 timmie]:

 [...]
 > > But here' a gui example:
 > >
 https://github.com/ipython/ipython/blob/master/examples/lib/ipkernel_wxapp.py
 >
 > This console is based on qt. It would be possible to call it and use it
 as a separate window. However, so far I was not able launch it from wxGUI
 because of various errors. Also it seems that the console (from the
 example above) does not quit with the wx app. Maybe someone will be more
 lucky.


 I think you are talking of the IPython QT Console.

 Since this is beyond this ticket, please follow up here:

 create IPython magic to launch GRASS wxGUI components Ipython qt console
 https://trac.osgeo.org/grass/ticket/1920

-- 
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] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-

Comment(by timmie):

 > On Sun, Nov 11, 2012 at 11:34 PM, Massimo Di Stefano:
 > > http://nbviewer.ipython.org/url/epi.whoi.edu/esr/GIS_GRASS-
 R_Example.ipynb
 [...]
 Since this is beyond this ticket, please follow up here:

 create IPython magic to control from IPython Notebook
 https://trac.osgeo.org/grass/ticket/1921

-- 
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] #1921: create IPython magic to control from IPython Notebook

[GRASS GIS]

#1921: create IPython magic to control from IPython Notebook
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Addons   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by timmie):

 Although this would be awesome and take the reproducible research [1]
 further, I do not know if this is in the scope of GRASS...

 [1]
 http://www.stanford.edu/~vcs/AAAS2011/1102_aaas_reproducibility_fperez.pdf

-- 
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] #1921: create IPython magic to control from IPython Notebook

[GRASS GIS]

#1921: create IPython magic to control from IPython Notebook
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Addons   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  Unspecified  |  
-+--
 from:
 https://trac.osgeo.org/grass/ticket/666#comment:6

 * there are demos with GRASS being run from inside IPython Notebook:
 http://nbviewer.ipython.org/url/epi.whoi.edu/esr/GIS_GRASS-R_Example.ipynb
 * the output pictures are currently simply empedded by statics PNG output
 * some interactivity would be nice.

 This could be achived by:
 * embedded OpenLayers (with query buttons, zoom, etc.)
 * launching an external wxGui window (similar to %edit magic)

-- 
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] #1920: create IPython magic to launch GRASS wxGUI components Ipython qt console

[GRASS GIS]

#1920: create IPython magic to launch GRASS wxGUI components Ipython qt console
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Addons   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by timmie):

 Actually, this is not really GRASS core scope...
 We have such a nice GUI.
 Why split it?
 Anyway.

-- 
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] #1920: create IPython magic to launch GRASS wxGUI components Ipython qt console

[GRASS GIS]

#1920: create IPython magic to launch GRASS wxGUI components Ipython qt console
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Addons   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  Unspecified  |  
-+--
 From:
 * https://trac.osgeo.org/grass/ticket/666#comment:9

 Create a set of magic commands to launch and control certain GRASS wxGui
 components from IPython qt console.

 components could be:
 * map window (display commands)
 * layer manager

-- 
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] #151: make documentation be full text searchable: use sphinx

[GRASS GIS]

#151: make documentation be full text searchable: use sphinx
-+--
 Reporter:  timmie   |   Owner:  epatton
 Type:  enhancement  |  Status:  assigned   
 Priority:  major|   Milestone:  7.0.0  
Component:  Docs | Version:  unspecified
 Keywords:   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--
Changes (by timmie):

  * component:  Website => Docs


-- 
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] #1919: add achors to documentation website

[GRASS GIS]

#1919: add achors to documentation website
-+--
 Reporter:  timmie   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Website  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 I would love to see achors appearing at website of the GRASS docs once the
 user hovers the headline.

 This way, we could easily reference sections of the docs in ML & support
 forums or even articles.

 Example:
 Sphinx generated:
 http://pythonhosted.org/Whoosh/intro.html#introduction-to-whoosh

 But Trac seems to have it too.

-- 
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] #151: make documentation be full text searchable: use sphinx

[GRASS GIS]

#151: make documentation be full text searchable: use sphinx
-+--
 Reporter:  timmie   |   Owner:  epatton
 Type:  enhancement  |  Status:  assigned   
 Priority:  major|   Milestone:  7.0.0  
Component:  Website  | Version:  unspecified
 Keywords:   |Platform:  Unspecified
  Cpu:  Unspecified  |  
-+--
Changes (by timmie):

 * cc: timmie (added)


Comment:

 So where are we now?

 * Keeping the HTML docs are apparently the consence
 * The current doc are not searchable
 * So can we user the technology behind the Sphinx search be used for
 GRASS?
 * What about other approaches like Whoosh [1]?

 Ideally, the search would be on the website but also in the wxGui.

 [1] http://pythonhosted.org/Whoosh/intro.html

-- 
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] #666: add a scripting console

[GRASS GIS]

#666: add a scripting console
--+-
  Reporter:  timmie   |   Owner:  grass-dev@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  python   
  Platform:  All  | Cpu:  x86-32   
--+-

Comment(by annakrat):

 Replying to [comment:7 timmie]:
 > So does this mean agreement or disagreement?
 >
 > the notebook is a beast that could not get integrated.
 > We would rather need to create a set of %magics to open the wxGui from
 within the IPython Notebook to
 > * get the power of scripting with GRASS, R, Scipy etc.
 > * use the power & comfort of GRASS wxGUI for display and interaction.
 >
 > => this would be a different enhancement request.
 >
 > But here' a gui example:
 >
 https://github.com/ipython/ipython/blob/master/examples/lib/ipkernel_wxapp.py

 This console is based on qt. It would be possible to call it and use it as
 a separate window. However, so far I was not able launch it from wxGUI
 because of various errors. Also it seems that the console (from the
 example above) does not quit with the wx app. Maybe someone will be more
 lucky.


 I haven't succeeded in launching wxGUI from IPython either. The GUI
 freezes. The [https://github.com/ipython/ipython/blob/master/examples/lib
 /gui-wx.py example] works at least, so it should be possible to make it
 work.

 Anna

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Markus Neteler]

On Sat, Apr 6, 2013 at 10:21 AM, Markus Neteler  wrote:
> On Sat, Apr 6, 2013 at 10:13 AM, Glynn Clements
>  wrote:
>> Markus Neteler wrote:
> ...
>>> main.c:22: error: storage size of 't' isn't known
>>> make: *** [OBJ.powerpc-ibm-aix5.3.0.0/main.o] Error 1
>>
>> In which directory? main.c could be anything?
>
> Ah sorry: tools/timer/main.c
>
> ...
>> Okay; "struct winsize" isn't actually specified by POSIX, but it
>> should exist somewhere if TIOCGWINSZ is defined. Not necessarily in
>> the same header as the TIOCGWINSZ definition. Again, it may be guarded
>> by a #if/#ifdef.
>>
>> On Linux, it's defined in both asm-generic/termios.h (kernel header)
>> and bits/ioctl-types.h (glibc header).
>
> I found this:
>
> /usr/include> grep TIOCGWINSZ */*
> sys/ioctl.h: * TIOCSWINSZ and TIOCGWINSZ -- in fact they are defined to be the
> sys/ioctl.h:#define TIOCGSIZE   TIOCGWINSZ
> sys/ioctl.h:#define TIOCGWINSZ   _IOR('t', 104, struct winsize)
> /* get window size */

I inspected the file and added _ALL_SOURCE=1:

...
checking whether the C compiler (gcc -ansi -D_ALL_SOURCE=1
-D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=200809L -Dinline= ) works... yes

Now tools/timer/main.c compiles as well as lib/gis/ls.c - hence the
types get defined.

Remains:
lib/gs/plot.c:34: error: conflicting types for 'nearest'

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

Re: [GRASS-dev] verbose in grass.array .write() function

[Johannes Radinger]

So actually verbose=True should then be removed from the function
so that it behaves like other GRASS modules and the verbosity level
setting is inherited from the script in which .write() is used?
Or is there any particular reason why verbosity level is 3 be default?
If not I could file a report for improvement.

/Johannes


On Sat, Apr 6, 2013 at 10:32 AM, Glynn Clements wrote:

>
> Johannes Radinger wrote:
>
> > in GRASS 6.5 the python array.write() function in
> >
> http://svn.osgeo.org/grass/grass/branches/develbranch_6/lib/python/array.py
> > has set verbose=TRUE. Is there any reason for that?
>
> It was probably added during development and not reverted.
>
> > It seems when using the .write() function in a personal
> > script the verbose-level is not parsed to that underlying function. So
> > even when in the script the quiet-flag is set, an output (progress,
> > percentage) is still printed. So maybe some lines like in
> >
> http://svn.osgeo.org/grass/grass/branches/develbranch_6/lib/python/raster.py
> > could be added for this function as well:
> > if quiet:
> > env['GRASS_VERBOSE'] = '0'
> > if verbose:
> > env['GRASS_VERBOSE'] = '3'
> > if overwrite:
> > env['GRASS_OVERWRITE'] = '1'
>
> That's not necessary; it should either pass quiet=True or pass neither
> quiet= nor verbose=, and allow the script's verbosity setting to be
> inherited.
>
> --
> Glynn Clements 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Glynn Clements]

Markus Neteler wrote:

> >> cat /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/include/sys/types.h
> >
> > Can you visually compare this file to the preprocessor output from
> ...
> 
> (file sent offlist for inspection)
> 
> > However: adding -D_POSIX_SOURCE=1 may help (glibc's features.h defines
> > _POSIX_SOURCE if _POSIX_C_SOURCE is set; AIX's might not).

That appears to be the case. Without _POSIX_SOURCE, only the
aforementioned types (ptrdiff_t, wchar_t, wctype_t, time_t, clock_t,
and size64_t) are defined.

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

Re: [GRASS-dev] verbose in grass.array .write() function

[Glynn Clements]

Johannes Radinger wrote:

> in GRASS 6.5 the python array.write() function in
> http://svn.osgeo.org/grass/grass/branches/develbranch_6/lib/python/array.py
> has set verbose=TRUE. Is there any reason for that?

It was probably added during development and not reverted.

> It seems when using the .write() function in a personal
> script the verbose-level is not parsed to that underlying function. So
> even when in the script the quiet-flag is set, an output (progress,
> percentage) is still printed. So maybe some lines like in
> http://svn.osgeo.org/grass/grass/branches/develbranch_6/lib/python/raster.py
> could be added for this function as well:
> if quiet:
> env['GRASS_VERBOSE'] = '0'
> if verbose:
> env['GRASS_VERBOSE'] = '3'
> if overwrite:
> env['GRASS_OVERWRITE'] = '1'

That's not necessary; it should either pass quiet=True or pass neither
quiet= nor verbose=, and allow the script's verbosity setting to be
inherited.

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Markus Neteler]

On Sat, Apr 6, 2013 at 10:13 AM, Glynn Clements
 wrote:
> Markus Neteler wrote:
...
>> main.c:22: error: storage size of 't' isn't known
>> make: *** [OBJ.powerpc-ibm-aix5.3.0.0/main.o] Error 1
>
> In which directory? main.c could be anything?

Ah sorry: tools/timer/main.c

...
> Okay; "struct winsize" isn't actually specified by POSIX, but it
> should exist somewhere if TIOCGWINSZ is defined. Not necessarily in
> the same header as the TIOCGWINSZ definition. Again, it may be guarded
> by a #if/#ifdef.
>
> On Linux, it's defined in both asm-generic/termios.h (kernel header)
> and bits/ioctl-types.h (glibc header).

I found this:

/usr/include> grep TIOCGWINSZ */*
sys/ioctl.h: * TIOCSWINSZ and TIOCGWINSZ -- in fact they are defined to be the
sys/ioctl.h:#define TIOCGSIZE   TIOCGWINSZ
sys/ioctl.h:#define TIOCGWINSZ   _IOR('t', 104, struct winsize)
/* get window size */

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

Re: [GRASS-dev] compilation of grass on AIX 7.1

[Glynn Clements]

Markus Neteler wrote:

> I tried:
> 
> gcc  -ansi -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=200809L -Dinline=
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
>-DPACKAGE=\""grassmods"\"
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -o OBJ.powerpc-ibm-aix5.3.0.0/main.o -c main.c
> main.c: In function 'main':
> main.c:22: error: storage size of 't' isn't known
> make: *** [OBJ.powerpc-ibm-aix5.3.0.0/main.o] Error 1

In which directory? main.c could be anything?

> gcc  -ansi -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=200809L -Dinline=
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
>   -DGRASS_VERSION_DATE=\"'2013'\" -DPACKAGE=\""grasslibs"\"
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -I/afs/mycluster/user/private/software/grass-7.0.svn_src_snapshot_2013_03_22/dist.powerpc-ibm-aix5.3.0.0/include
> -o OBJ.powerpc-ibm-aix5.3.0.0/ls.o -c ls.c
> ls.c: In function 'G_ls_format':
> ls.c:177: error: storage size of 'size' isn't known
> ls.c:179: error: invalid application of 'sizeof' to incomplete type
> 'struct winsize'
> make[3]: *** [OBJ.powerpc-ibm-aix5.3.0.0/ls.o] Error 1

Okay; "struct winsize" isn't actually specified by POSIX, but it
should exist somewhere if TIOCGWINSZ is defined. Not necessarily in
the same header as the TIOCGWINSZ definition. Again, it may be guarded
by a #if/#ifdef.

On Linux, it's defined in both asm-generic/termios.h (kernel header)
and bits/ioctl-types.h (glibc header).

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

Re: [GRASS-dev] [GRASS GIS] #1918: Missing $(RASTERLIB) $(RASTERDEP) in vector/v.in.region/Makefile

[GRASS GIS]

#1918: Missing $(RASTERLIB) $(RASTERDEP) in vector/v.in.region/Makefile
-+--
  Reporter:  torsti  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Vector  | Version:  svn-trunk
Resolution:  fixed   |Keywords:  v.in.region  
  Platform:  Linux   | Cpu:  Unspecified  
-+--

Comment(by mmetz):

 Replying to [comment:2 hamish]:
 > from the v.in.region help page:
 >
 >  "If the output of v.in.region is to be used for raster
 > reprojection, the -d flag should be used after setting the
 > region to the raster map to be reprojected with
 > r.proj."
 >
 > It would be good to explain why, and what the flag does to solve it.

 From the r.proj manual:
 "A more involved, but more accurate, way to do this is to generate a
 vector "box" map of the region in the source location using v.in.region.
 This "box" map is then reprojected into the target location with v.proj.
 Next the region in the target location is set to the extent of the new
 vector map with g.region along with the desired raster resolution [...]."

 The extents of the reprojected vector map are often smaller than the
 extents of the reprojected raster map would be, because v.in.region only
 creates points at the box corners. If additional vertices are inserted
 according to the raster resolution, the extents of the reprojected vector
 are different, i.e. larger. In the attached screenshot, the standard
 reprojected vector is in red, the densified vector is in blue. The source
 projection was European LAEA (EPSG:3035), the target projection was
 latlong. The effect of the -d flag for v.in.region is similar to the
 effect of the -p flag for r.proj.

 Markus M

-- 
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] #1918: Missing $(RASTERLIB) $(RASTERDEP) in vector/v.in.region/Makefile

[GRASS GIS]

#1918: Missing $(RASTERLIB) $(RASTERDEP) in vector/v.in.region/Makefile
-+--
  Reporter:  torsti  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Vector  | Version:  svn-trunk
Resolution:  fixed   |Keywords:  v.in.region  
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Changes (by hamish):

  * keywords:  => v.in.region


Comment:

 from the v.in.region help page:

  "If the output of v.in.region is to be used for raster
 reprojection, the -d flag should be used after setting the
 region to the raster map to be reprojected with
 r.proj."

 It would be good to explain why, and what the flag does to solve it.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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