[GRASS-dev] Re: [GRASS GIS] #196: wxGUI interface hangs, when adding maps to display
#196: wxGUI interface hangs, when adding maps to display ---+ Reporter: rmatev| Owner: grass-dev@lists.osgeo.org Type: defect| Status: reopened Priority: minor | Milestone: 6.4.0 Component: wxGUI | Version: 6.3.0 Resolution:|Keywords: Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by cmbarton): I've just tested this on 6.4 and 6.5 svn with Mac OSX. I have no problems. No hanging with DEBUG=4 set. Is this still a problem for anyone else? Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/196#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #196: wxGUI interface hangs, when adding maps to display
#196: wxGUI interface hangs, when adding maps to display
---+
Reporter: rmatev| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: reopened
Priority: minor | Milestone: 6.4.0
Component: wxGUI | Version: 6.3.0
Resolution:|Keywords:
Platform: MSWindows XP | Cpu: x86-32
---+
Comment (by martinl):
Replying to [comment:4 cmbarton]:
I've just tested this on 6.4 and 6.5 svn with Mac OSX. I have no
problems. No hanging with DEBUG=4 set. Is this still a problem for anyone
else?
yes,
{{{
g.gisenv set=DEBUG=5
}}}
* start wxGUI
* add new vector map layer
* display
wxGUI stops responding because of amount of debug messages redirected to
command output window.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/196#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #748: Inconsistency (?) in GUI v.db.connect
#748: Inconsistency (?) in GUI v.db.connect -+-- Reporter: pvanbosgeo | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution: |Keywords: v.db.connect Platform: Linux | Cpu: x86-64 -+-- Changes (by martinl): * keywords: = v.db.connect * component: default = wxGUI -- Ticket URL: http://trac.osgeo.org/grass/ticket/748#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #748: Inconsistency (?) in GUI v.db.connect
#748: Inconsistency (?) in GUI v.db.connect -+-- Reporter: pvanbosgeo | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution: |Keywords: v.db.connect Platform: Linux | Cpu: x86-64 -+-- Changes (by martinl): * cc: grass-dev@lists.osgeo.org (added) * owner: grass-dev@lists.osgeo.org = martinl * status: new = assigned -- Ticket URL: http://trac.osgeo.org/grass/ticket/748#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4 release
Hi, 2009/9/11 Michael Barton michael.bar...@asu.edu: +1^10 for releasing GRASS 6.4.0 ;-) [...] There may be another Windows issue, but I'm not sure. When trying to create a location from a georeferenced file in Windows XP, 2 student got the same error I will be able to try to fix some Windows-related bugs later. My Windows are completely broken after I have installed SP3, so I need to reinstall the whole system. Thanks Microsoft for providing SP which destroys working (almost) OS ;-) Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] color tables
Hamish wrote: I often get a question why there aren't images of color tables in GRASS GUI along with their names. Is this technically feasible? ... I am thinking about adding them to the r.colors man page, thumbnail images of the colortables now added in 6.5 and 7 svn in the raster/r.colors/ dir. These should be generated as part of the build process. Otherwise, there's no guarantee that they actually match the colour tables in lib/gis/colors (shouldn't those have been moved to lib/raster?). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #746: v.out.ascii with column parameter: segfault
#746: v.out.ascii with column parameter: segfault --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Vector | Version: 6.4.0 RCs Resolution: |Keywords: Platform: Linux| Cpu: x86-64 --+- Comment (by glynn): Replying to [comment:5 neteler]: Various dbString functions expect the target value to have been initialised, but value is uninitialised. It needs to be initialised with: Is attached patch ok? I suggest using an initialiser; try r39121. -- Ticket URL: https://trac.osgeo.org/grass/ticket/746#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #746: v.out.ascii with column parameter: segfault
#746: v.out.ascii with column parameter: segfault --+- Reporter: neteler | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: normal | Milestone: 6.4.0 Component: Vector | Version: 6.4.0 RCs Resolution: fixed|Keywords: Platform: Linux| Cpu: x86-64 --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Thanks, seems to help. Backported. Closing. -- Ticket URL: https://trac.osgeo.org/grass/ticket/746#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #542: grass7 vector libraries modifications
#542: grass7 vector libraries modifications --+- Reporter: mmetz| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: |Keywords: Platform: All | Cpu: All --+- Changes (by martinl): * cc: martinl (added) * priority: minor = major -- Ticket URL: http://trac.osgeo.org/grass/ticket/542#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #608: GIS.m: Lat/Lon support broken in Map Display zooms
#608: GIS.m: Lat/Lon support broken in Map Display zooms --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: blocker | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution: |Keywords: gis.m, LL Platform: All | Cpu: All --+- Comment (by hamish): It will still be broken. (afaik no one has touched the code since I last did). from memory: try with the etopo2 dataset or some 180E-180W, 90S-90N raster with a 15 degree d.grid overlay. adjust map box so you have white bands at the top and bottom. zoom in, then zoom out and back out to global view. compare the position shown on the status bar with what should be the value from the grid lines. you will notice it counts as pixels from the top of the map window, not from the bottom of the upper white 90N band. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/608#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hamish): Replying to [comment:12 cmbarton]: Works fine in GRASS 6.4 and 6.5 svn on Mac OS X. yeah, it's only on WinGrass. I think Maris committed a fix for this in 6.5svn, but it awaits review backporting by someone who understands Tcl better than I do. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:13 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4 release
Michael wrote: To follow up on a recent thread, I'm also in favor of trying to get 6.4 released. I know of 2 major issues 1) v.delaunay is still badly broken http://trac.osgeo.org/grass/ticket/660 2) nviz will not launch from the wxpython menu in Windows. Because this does launch from the Msys command line, I suspect that it is something in the wxpython code (perhaps menuform.py). I don't think this is the same as http://trac.osgeo.org/grass/ticket/627 see release critical summary here: https://trac.osgeo.org/grass/report/13 to take the first one on the list, https://trac.osgeo.org/grass/ticket/595 the g.version Makefile fails on Windows. Also the wxGUI Help-About version of the GPL(+authors) is broken so there is no straight way to inform the users of their rights under the GPL, which is a mandatory requirement for release. There may be another Windows issue, but I'm not sure. When trying to create a location from a georeferenced file in Windows XP, 2 student got the same error r.in.gdal input=F:\Documentele mele\GIS DataBase\SRTM_ff03_p184r028.tif\SRTM_ff03_p184r028.tif output=GIS_Group title=S_Carpathians_Romania location=Romania_UTM ERROR: region for current mapset is not set run g.region this was bug #654 in rc5 I think. If so, it is fixed soon after / sorry about the trouble, I get to wear the brown paper bag. Was it self-built? AFAIK Colin and JEF both updated to newer 6.4.0svn checkouts now. go, go, go! Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #595: WinGRASS g.version -c fails
#595: WinGRASS g.version -c fails ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: blocker | Milestone: 6.4.0 Component: License | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gpl Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hellik): in the grass64 delivered by the osgeo4w-stack g.version -c works in the self compiled grass65-devel (rev39115) the$GISBASE/etc/VERSION is empty -- Ticket URL: https://trac.osgeo.org/grass/ticket/595#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] some impressions on the wx interface
Dear devs, Recently we had a workshop on SAGA+GRASS+R at the Geomorphometry2009 conference (www.geomorphometry.org). Before the workshop I was using the old tcl/tk interface (pretty much because of laziness, I'm used to it), but during the workshop most students were using Windows, so the WX interface was the default. Besides some bugs with the Windows version of GRASS, it went well. Some of the issues I observed during the workshop follow, so we can discuss ways to improve GRASS. One thing is that the WX interface doesn't open a terminal (at least in Windows), so if one is thinking about running GRASS+R, with GRASS on top of R, there is no way. Or is there? I noticed that the students were using most the load map layers into workspace icon, instead of add raster or add vector. I don't know if this is because load maps is more to the left of the toolbar, and if you read from left to right, you see it before the others. I think that it would be better if the three workspace icons were at the far right of the toolbar. Also I would put the add raster and add vector icons with a different image, to highlight them from the others. In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. In GIS manager, it looks to me that the maps for each display and command output are tabs, right? using a wx.notebook? in this case, I have to say that they don't look like tabs, and this always got me a little confused. If they had a real tab-like appearance, it would be better to understand the way the GUI works, because anyone that's new to the interface would know that there are two tabs with different contents. Also it would be very nice if instead of maps for each display, we had maps for display 1, maps for display 2, etc. Also, using the mouse scroll wheel to navigate between tabs, IMO, is a must-have. That includes all tabs, the display tabs in gism and the options tabs in the commands dialogs. I also noticed that one can close tabs in the command dialog. why? the arrows to scroll to tabs that may not be visible is OK (although I would prefer to have all the tabs shown, even if that meant two rows of tabs), but closing tabs shouldn't be an option. Maybe we can save some space using regular square tabs instead of the tabs with that triangular ending. The dialog name for r.shaded.relief is raded.relief. Didn't check other dialogs. And I noticed that I can't change the HTML browser (Ubuntu 9.04, latest GRASS SVN). It always call Konqueror. I tried changing GRASS_HTML_BROWSER to firefox or chromium-browser, but unsuccessfully. that's it for now. I'll use only the WX interface now, so I might come back with more feedback soon. cheers Carlos -- Carlos Henrique Grohmann - Geologist D.Sc. a.k.a. Guano - Linux User #89721 ResearcherID: A-9030-2008 http://digitalelevation.blogspot.com http://www.igc.usp.br/pessoais/guano _ Can’t stop the signal. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
Hamish - are sure this is still a problem - I am at home now so I cannot test winGRASS until Monday, but we have been using winGRASSRC5 for 3 weeks and haven't seen the problem. maybe somebody with winGRASS on hand can check whether this is still an issue. Helena On Sep 11, 2009, at 4:37 AM, GRASS GIS wrote: #593: WinGRASS GIS.m: cannot select maps from mapset GUI --- + Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 --- + Comment (by hamish): Replying to [comment:12 cmbarton]: Works fine in GRASS 6.4 and 6.5 svn on Mac OS X. yeah, it's only on WinGrass. I think Maris committed a fix for this in 6.5svn, but it awaits review backporting by someone who understands Tcl better than I do. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:13 GRASS GIS http://grass.osgeo.org ___ 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
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Changes (by cmbarton): * cc: maris@gmail.com (added) Comment: I can't test this on windows unless I have a binary to give to one of my students who uses windows. I've been out of the loop for awhile. But if Maris can give me the fix, I can manually insert it into a 6.4 Windows binary and see if it works. Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:14 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: GRASS-dev] some impressions on the wx interface
Thanks for the thoughtful review and summary Carlos. Michael On Sep 11, 2009, at 8:02 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 11 Sep 2009 12:01:51 -0300 From: Carlos Grohmann carlos.grohm...@gmail.com Subject: [GRASS-dev] some impressions on the wx interface To: grass-dev grass-dev@lists.osgeo.org Message-ID: bd07447b0909110801x5987a7e0jea45d6441253e...@mail.gmail.com Content-Type: text/plain; charset=windows-1252 Dear devs, Recently we had a workshop on SAGA+GRASS+R at the Geomorphometry2009 conference (www.geomorphometry.org). Before the workshop I was using the old tcl/tk interface (pretty much because of laziness, I'm used to it), but during the workshop most students were using Windows, so the WX interface was the default. Besides some bugs with the Windows version of GRASS, it went well. Some of the issues I observed during the workshop follow, so we can discuss ways to improve GRASS. One thing is that the WX interface doesn't open a terminal (at least in Windows), so if one is thinking about running GRASS+R, with GRASS on top of R, there is no way. Or is there? I noticed that the students were using most the load map layers into workspace icon, instead of add raster or add vector. I don't know if this is because load maps is more to the left of the toolbar, and if you read from left to right, you see it before the others. I think that it would be better if the three workspace icons were at the far right of the toolbar. Also I would put the add raster and add vector icons with a different image, to highlight them from the others. In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. In GIS manager, it looks to me that the maps for each display and command output are tabs, right? using a wx.notebook? in this case, I have to say that they don't look like tabs, and this always got me a little confused. If they had a real tab-like appearance, it would be better to understand the way the GUI works, because anyone that's new to the interface would know that there are two tabs with different contents. Also it would be very nice if instead of maps for each display, we had maps for display 1, maps for display 2, etc. Also, using the mouse scroll wheel to navigate between tabs, IMO, is a must-have. That includes all tabs, the display tabs in gism and the options tabs in the commands dialogs. I also noticed that one can close tabs in the command dialog. why? the arrows to scroll to tabs that may not be visible is OK (although I would prefer to have all the tabs shown, even if that meant two rows of tabs), but closing tabs shouldn't be an option. Maybe we can save some space using regular square tabs instead of the tabs with that triangular ending. The dialog name for r.shaded.relief is raded.relief. Didn't check other dialogs. And I noticed that I can't change the HTML browser (Ubuntu 9.04, latest GRASS SVN). It always call Konqueror. I tried changing GRASS_HTML_BROWSER to firefox or chromium-browser, but unsuccessfully. that's it for now. I'll use only the WX interface now, so I might come back with more feedback soon. cheers Carlos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #608: GIS.m: Lat/Lon support broken in Map Display zooms
#608: GIS.m: Lat/Lon support broken in Map Display zooms --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: blocker | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution: |Keywords: gis.m, LL Platform: All | Cpu: All --+- Comment (by cmbarton): Thanks for the additional info. I'll try this specific test and see what happens. Michael -- Ticket URL: https://trac.osgeo.org/grass/ticket/608#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] i.plr.py Probabilistic Label Relaxation
Dear GRASS developers,
Today I finished a first attempt at writing a GRASS script in python for
probabilistic label relaxation.
The script uses a given sigfile to run i.maxlik for _every_ given
signature and save the reject threshold results.
These results are used as input for the relaxation process.
This first version is v e r y slow (~ 2 min) for a 150x200 cell region
and also the assignment of probabilities for 2 classes being next to
each other is still very basic (1.0 if the classes are the same, 0.5 if
not). But anyway, it seems to be working!
This will be part of my diploma thesis and I would like to hear your
comments. Naturally I am very interested in speeding up the whole process...
This is my first self-made script for GRASS (not counting small
helper-scripts), so please be kind ;)
best regards,
Georg
#!/usr/bin/env python
#
#
#
# MODULE: i.plr.py
# AUTHOR(S): Georg Kaspar
# PURPOSE: Probabilistic label relaxation, postclassification filter
# COPYRIGHT: (C) 2009
#
# This program is free software under the GNU General Public
# License (=v2). Read the file COPYING that comes with GRASS
# for details.
#
#
#%Module
#% description: Probabilistic label relaxation, postclassification filter
#%End
#%option
#% key: maxlik
#% type: string
#% description: classification results
#% required : yes
#%end
#%option
#% key: group
#% type: string
#% description: image group to be used
#% required : yes
#%end
#%option
#% key: subgroup
#% type: string
#% description: image subgroup to be used
#% required : yes
#%end
#%option
#% key: sigfile
#% type: string
#% description: Path to sigfile
#% required : yes
#%end
#%option
#% key: output
#% type: string
#% description: Name for resulting raster file
#% required : no
#%end
#%option
#% key: iterations
#% type: integer
#% description: Number of iterations (1 by default)
#% required : no
#%end
import sys
import os
import numpy
import grass.script as grass
from osgeo import gdal, gdalnumeric, gdal_array
from osgeo.gdalconst import GDT_Byte
def getMetadata():
env = grass.gisenv()
global GISDBASE
global LOCATION_NAME
global MAPSET
GISDBASE = env['GISDBASE']
LOCATION_NAME = env['LOCATION_NAME']
MAPSET = env['MAPSET']
def splitSignatures(path, sigfile):
# split signature file into subfiles with 1 signature each
stream_in = open(path + sigfile, r)
stream_in.next() # skip header
counter = 0
i = 1
for line in stream_in:
if (i % 7) == 1:
counter += 1
stream_out = open(path + plr_ + str(counter) + .sig, w)
stream_out.write(#produced by i.plr\n)
stream_out.write(line)
if (i % 7) == 0:
stream_out.close()
i += 1
stream_in.close()
return counter
def normalizeProbabilities(counter):
arg =
for i in range(counter):
arg = arg + +plr_rej_ + str(i)
arg = arg.strip('+')
print calculating multiplicands, arg= + arg
grass.run_command(r.mapcalc, multiplicand = 1./( + arg + ))
for i in range(counter):
print normalizing probabilities for class + str(i)
grass.run_command(r.mapcalc, plr_rej_norm = plr_rej_ + str(i) + *multiplicand)
grass.run_command(g.rename, rast=plr_rej_norm,plr_rej_norm_ + str(i))
def getProbability(a,b):
# TODO: Implement this!!!
if a == b:
return 1
else:
return 0.5
def cleanUp(path):
os.system(rm + path + /plr_*.*)
os.system(rm /tmp/plr_*.*)
grass.run_command(g.mremove, flags=f, quiet=True, rast=plr_*)
def plr_filter(probabilities, width, height, classes, iterations):
print str(iterations) + iteration(s) to go...
print Image size: + str(width) + x + str(height)
# create an empty n-dimesional array containing results
results = numpy.ones((classes,height,width))
progress = 0
# for each pixel (except border)
for y in range(1, height-1):
p = int(float(y)/height * 100)
if p progress:
print str(p) + % done
progress = p
for x in range(1, width-1):
p = [0]
q = [0]
# for all classes create neighbourhood and extract probabilities
for c in range(1, classes+1):
q.append(neighbourhoodFunction(probabilities, x, y, c, classes))
p.append(probabilities[c-1, y, x])
# resulting cell contains the product of class probability and
# neighbourhood-function divided by their sums so that each set of
# probabilities sums to one
for c in range(1, classes+1):
#results[c-1,y,x] = (p[c] + q[c]) / float((sum(p) + sum(q)))
results[c-1,y,x] = p[c] + q[c]
print
if
Re: [GRASS-dev] some impressions on the wx interface
Little bit of cosmetics to wxGUI would indeed help, especially for new users - see my comments below: On Sep 11, 2009, at 11:01 AM, Carlos Grohmann wrote: One thing is that the WX interface doesn't open a terminal (at least in Windows), so if one is thinking about running GRASS+R, with GRASS on top of R, there is no way. Or is there? yes, there is, we open GRASS using GRASS+MSYS icon (the one with grass and blue M) and that opens wxGUI and shell. This makes the environment on linux, Mac and WinGRASS very similar to each other and so far worked great for me. The one very confusing thing is that when you try to run any d.* command it says not yet implemented so it looks like unfinished thing which may be OK for RC but not for the final release. I suggest to change the message to something like not applicable without X11 support, please use appropriate icons, see wxGUI help although people generally won't know what X11 is - so maybe somebody has a better suggestion? And as I said before - I am missing the d.* commands sooo much! I noticed that the students were using most the load map layers into workspace icon, instead of add raster or add vector. I don't know if this is because load maps is more to the left of the toolbar, and if you read from left to right, you see it before the others. I think that it would be better if the three workspace icons were at the far right of the toolbar. Also I would put the add raster and add vector icons with a different image, to highlight them from the others. I am not sure about this - I did not observe students using load map layers - maybe you have shown the students the load map layers first and they stick to it even after they find out about add raster. In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. YES!!! Everybody here complains that they cannot find the legend button. Even if you read the wxGUI help - it is hard to remember. In GIS manager, it looks to me that the maps for each display and command output are tabs, right? using a wx.notebook? in this case, I have to say that they don't look like tabs, and this always got me a little confused. If they had a real tab-like appearance, it would be better to understand the way the GUI works, because anyone that's new to the interface would know that there are two tabs with different contents. I would agree with this, although most students figured this out. Given that wxGUI is completely new and minimally tested by broader users community it is quite amazing how robust it is and I would vote for releasing it as a default GUI for both Mac and linux, as it is now for winGRASS. It may be worth to spend some time on polishing it for GRASS64 final release, rather than having to maintain two GUIs - I found that some people who learned TclTK GUI stick to it and are hesitant to switch. Helena Also it would be very nice if instead of maps for each display, we had maps for display 1, maps for display 2, etc. Also, using the mouse scroll wheel to navigate between tabs, IMO, is a must-have. That includes all tabs, the display tabs in gism and the options tabs in the commands dialogs. I also noticed that one can close tabs in the command dialog. why? the arrows to scroll to tabs that may not be visible is OK (although I would prefer to have all the tabs shown, even if that meant two rows of tabs), but closing tabs shouldn't be an option. Maybe we can save some space using regular square tabs instead of the tabs with that triangular ending. The dialog name for r.shaded.relief is raded.relief. Didn't check other dialogs. And I noticed that I can't change the HTML browser (Ubuntu 9.04, latest GRASS SVN). It always call Konqueror. I tried changing GRASS_HTML_BROWSER to firefox or chromium-browser, but unsuccessfully. that's it for now. I'll use only the WX interface now, so I might come back with more feedback soon. cheers Carlos -- Carlos Henrique Grohmann - Geologist D.Sc. a.k.a. Guano - Linux User #89721 ResearcherID: A-9030-2008 http://digitalelevation.blogspot.com http://www.igc.usp.br/pessoais/guano _ Can’t stop the signal. ___ 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
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hellik): grass65 selfcompiled in the osgeo4w-stack on WinVista32 rev39115 nc-dataset mapset: user1 there's no problem to choose a vector or raster from another mapset like PERMANENT in the nc-dataset. i've tried this with spaces (C:\gis data\grassdata) and without spaces (C:\gisdata\grassdata) in the path to the location. -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:15 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some impressions on the wx interface
Hello Helena and Carlos, Thank you for valuable comments on GUI. Helena Mitasova pisze: Little bit of cosmetics to wxGUI would indeed help, especially for new users - see my comments below: On Sep 11, 2009, at 11:01 AM, Carlos Grohmann wrote: In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. YES!!! Everybody here complains that they cannot find the legend button. Even if you read the wxGUI help - it is hard to remember. Which version are we talking about? http://grass.itc.it/grass64/manuals/html64_user/icons/grass2/element-add.png http://grass.itc.it/grass64/manuals/html64_user/icons/silk/overlays.png http://grass.itc.it/grass64/manuals/html64_user/icons/grass/gui-rastanalyze.gif I agree with you. None of them is good :) Any idea how it should look like? Explicit version like this one? http://robert.szczepanek.pl/icon/0.1/overlay-add.png Robert ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
Helena wrote: - are sure this is still a problem - I am at home now so I cannot test winGRASS until Monday, but we have been using winGRASSRC5 for 3 weeks and haven't seen the problem. It is with the tcltk/gis.m GUI, not the wxpython GUI. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hellik): Replying to [comment:15 hellik]: grass65 selfcompiled in the osgeo4w-stack on WinVista32 rev39115 nc-dataset mapset: user1 there's no problem to choose a vector or raster from another mapset like PERMANENT in the nc-dataset. i've tried this with spaces (C:\gis data\grassdata) and without spaces (C:\gisdata\grassdata) in the path to the location. tested in the tcltk/gis.m GUI -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:16 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r39128 automatically choose appropriate geometry type
Hi, I am a bit concerned that devbr6 r39128 Added code to automatically choose an appropriate geometry type for output. breaks backwards compatibility with earlier grass 6.x. (creates different output from same script) but I don't know much about what the before/after issue looks like here to be sure. of course for grass7 it is fine to change behaviour if it's an improvement. comments? thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by cmbarton): Is this relevant anymore? If the problem is 1) with the TclTk GUI and not wxpython, 2) only in Windows, and 3) if wxpython is the default GUI for WinGRASS 6.4, do we need to worry about it? Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/593#comment:17 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some impressions on the wx interface
Thanks for more comments. See below for some responses and ideas. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Sep 11, 2009, at 2:12 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 11 Sep 2009 13:28:56 -0400 From: Helena Mitasova hmit...@unity.ncsu.edu Subject: Re: [GRASS-dev] some impressions on the wx interface To: Carlos Grohmann carlos.grohm...@gmail.com Cc: grass-dev grass-dev@lists.osgeo.org Message-ID: cff877e3-0a7d-4920-88b0-85f9709f9...@unity.ncsu.edu Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Little bit of cosmetics to wxGUI would indeed help, especially for new users - see my comments below: On Sep 11, 2009, at 11:01 AM, Carlos Grohmann wrote: One thing is that the WX interface doesn't open a terminal (at least in Windows), so if one is thinking about running GRASS+R, with GRASS on top of R, there is no way. Or is there? yes, there is, we open GRASS using GRASS+MSYS icon (the one with grass and blue M) and that opens wxGUI and shell. This makes the environment on linux, Mac and WinGRASS very similar to each other and so far worked great for me. The one very confusing thing is that when you try to run any d.* command it says not yet implemented so it looks like unfinished thing which may be OK for RC but not for the final release. I suggest to change the message to something like not applicable without X11 support, please use appropriate icons, see wxGUI help although people generally won't know what X11 is - so maybe somebody has a better suggestion? And as I said before - I am missing the d.* commands sooo much! The old d.* commands will not work in GRASS 7...at all because of the change in the underlying display architecture. Remember, they dumped displays to a generic X window. To get an image into a canvas (TclTk or wxPython) is considerably more complicated, though you can do a lot more with it once it's there. The reason for the message is that Jachim Czpicky originally, and Martin Landa subsequently have thought about the possibility of having the command parser recognize a d.* command and display the result in a wxpython canvas. This sort of works in the Mac and Unix from the wxpython command parser, but I don't think that the python scripts to do this from a terminal are functional (Martin can correct me on this if I'm wrong). However, it seems to me better to wait until the display architecture is more finalized in GRASS 7 to do this. You can still display in x11 on GRASS 6 however. Maybe we should change the message for windows, however. I'm not sure where that message would live if you are talking about this from the Msys terminal. I noticed that the students were using most the load map layers into workspace icon, instead of add raster or add vector. I don't know if this is because load maps is more to the left of the toolbar, and if you read from left to right, you see it before the others. I think that it would be better if the three workspace icons were at the far right of the toolbar. Also I would put the add raster and add vector icons with a different image, to highlight them from the others. I am not sure about this - I did not observe students using load map layers - maybe you have shown the students the load map layers first and they stick to it even after they find out about add raster. There seems some logic to putting all the layer add buttons to the left and the workspace buttons to the right, but I don't have strong feelings about it. In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. YES!!! Everybody here complains that they cannot find the legend button. Even if you read the wxGUI help - it is hard to remember. Robert's new proposed button is much better. In GIS manager, it looks to me that the maps for each display and command output are tabs, right? using a wx.notebook? in this case, I have to say that they don't look like tabs, and this always got me a little confused. If they had a real tab-like appearance, it would be better to understand the way the GUI works, because anyone that's new to the interface would know that there are two tabs with different contents. I would agree with this, although most students figured this out. Maybe change the background color of the bar behind the tabs if that is possible? Given that wxGUI is completely new and minimally tested by broader users community it is quite amazing how robust it is and I would vote for releasing it as
Re: [GRASS-dev] some impressions on the wx interface
On Sep 11, 2009, at 2:12 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 11 Sep 2009 22:37:25 +0200 From: Robert Szczepanek rob...@szczepanek.pl Subject: Re: [GRASS-dev] some impressions on the wx interface To: Helena Mitasova hmit...@unity.ncsu.edu Cc: Carlos Grohmann carlos.grohm...@gmail.com,grass-dev grass-dev@lists.osgeo.org Message-ID: 4aaab505.9070...@szczepanek.pl Content-Type: text/plain; charset=windows-1252 Hello Helena and Carlos, Thank you for valuable comments on GUI. Helena Mitasova pisze: Little bit of cosmetics to wxGUI would indeed help, especially for new users - see my comments below: On Sep 11, 2009, at 11:01 AM, Carlos Grohmann wrote: In the Map Display, the overlay icon doesn't really mean much, I think that a different image would help, or even three buttons, one for legend, one for north arrow and on for text. YES!!! Everybody here complains that they cannot find the legend button. Even if you read the wxGUI help - it is hard to remember. Which version are we talking about? This one http://grass.itc.it/grass64/manuals/html64_user/icons/grass2/element-add.png I agree with you. None of them is good :) Any idea how it should look like? Explicit version like this one? http://robert.szczepanek.pl/icon/0.1/overlay-add.png Big improvement from my perspective. Thanks Michael Robert ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some impressions on the wx interface
Hello Helena and Robert. On Fri, Sep 11, 2009 at 14:28, Helena Mitasova hmit...@unity.ncsu.edu wrote: I noticed that the students were using most the load map layers into workspace icon, instead of add raster or add vector. I don't know if this is because load maps is more to the left of the toolbar, and if you read from left to right, you see it before the others. I think that it would be better if the three workspace icons were at the far right of the toolbar. Also I would put the add raster and add vector icons with a different image, to highlight them from the others. I am not sure about this - I did not observe students using load map layers - maybe you have shown the students the load map layers first and they stick to it even after they find out about add raster. Actually I didn't even know about the load map before the workshop (wasn't using the wx interface much). I always use (and teach) the add raster. But the workshop was very fast-paced, so maybe they got a little lost and start hovering the mouse over the GUI to find out what the icons do, and starting from the left, load maps comes before add raster.. I still think the workspace icons should go to the far right of the toolbar. On Fri, Sep 11, 2009 at 17:37, Robert Szczepanek rob...@szczepanek.pl wrote: Which version are we talking about? http://grass.itc.it/grass64/manuals/html64_user/icons/grass2/element-add.png http://grass.itc.it/grass64/manuals/html64_user/icons/silk/overlays.png http://grass.itc.it/grass64/manuals/html64_user/icons/grass/gui-rastanalyze.gif I agree with you. None of them is good :) Any idea how it should look like? Explicit version like this one? http://robert.szczepanek.pl/icon/0.1/overlay-add.png I forgotto say, I'm using the default grass2 icon set. The explicit one you pointed is better, but still maybe one icon per overlay? (legend, north arrow, text)? cheers Carlos -- Carlos Henrique Grohmann - Geologist D.Sc. a.k.a. Guano - Linux User #89721 ResearcherID: A-9030-2008 http://digitalelevation.blogspot.com http://www.igc.usp.br/pessoais/guano _ Can’t stop the signal. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some impressions on the wx interface
Michael Barton wrote: And as I said before - I am missing the d.* commands sooo much! The old d.* commands will not work in GRASS 7...at all because of the change in the underlying display architecture. The commands work fine; they just behave differently in terms of where the resulting image ends up. Remember, they dumped displays to a generic X window. They generated output via the current monitor, which may or may not have been an X monitor. To get an image into a canvas (TclTk or wxPython) is considerably more complicated, though you can do a lot more with it once it's there. The reason for the message is that Jachim Czpicky originally, and Martin Landa subsequently have thought about the possibility of having the command parser recognize a d.* command and display the result in a wxpython canvas. Trying to recognise d.* commands prior to execution is unwise; e.g. this probably won't work if the command is a user script which invokes d.* commands. It would make more sense to assume that any command may generate output, and to allow for this by setting all relevant environment variables. This sort of works in the Mac and Unix from the wxpython command parser, but I don't think that the python scripts to do this from a terminal are functional (Martin can correct me on this if I'm wrong). However, it seems to me better to wait until the display architecture is more finalized in GRASS 7 to do this. I'm unaware of any planned changes to the way that the display library works. I'm not anticipating any significant changes, although specific features can be added if necessary. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hamish): Replying to [comment:17 cmbarton]: Is this relevant anymore? To me, yes. Others are of course free to decide that for themselves and spend their time worrying about issues they find more interesting, as they like. bugs we know about should be fixed. especially ones that cripple an entire subsystem. anyway, this is just a small backport, not a huge investment in/redirection of effort. The larger problem on spaces in path names is of course another matter. I'm still a bit frustrated that the MSys devs won't even take patches for this class of bug. I would also note that making things more robust on WinGrass typically has the byproduct of making thinks slightly more robust on other platforms as well. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/593#comment:18 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #593: WinGRASS GIS.m: cannot select maps from mapset GUI
#593: WinGRASS GIS.m: cannot select maps from mapset GUI ---+ Reporter: hamish| Owner: marisn Type: defect| Status: reopened Priority: critical | Milestone: 6.4.0 Component: Tcl | Version: 6.4.0 RCs Resolution:|Keywords: wingrass gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by cmbarton): If it's just a backport, I'm definitely in favor doing this. Like I said, I can probably stick a TclTk patch into a student's 6.4 Windows binary to test this if it is a help. To do this on Windows, however, it will be much easier if I get the entire patched tcltk module instead of a patch file. Michael -- Ticket URL: https://trac.osgeo.org/grass/ticket/593#comment:19 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some impressions on the wx interface
YES!!! Everybody here complains that they cannot find the legend button. Even if you read the wxGUI help - it is hard to remember. Which version are we talking about? This one http://grass.itc.it/grass64/manuals/html64_user/icons/grass2/element-add.png oh, I always looked right past that; never noticed what it did. I agree with you. None of them is good :) Any idea how it should look like? Explicit version like this one? http://robert.szczepanek.pl/icon/0.1/overlay-add.png Big improvement from my perspective. I agree. Any objections to renaming the mini-menu to Add decoration from Add overlay? Overlay might be confused with raster overlays, and is otherwise not very clear in its meaning. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] suspicious warnings while compiling GRASS trunk (r39080)
Ivan Shmakov wrote: make[2]: Entering directory `/var/home/ivan/devel/grass-trunk-r39080/raster/r.mapcalc' map.c:344: warning: cast to pointer from integer of different size Not quite sure about this one. This is a bug, introduced in r38099, along with simlar bugs affecting d.legend and r.to.vect. G_get_cat() took a CELL argument (so FCELL or DCELL arguments will be implicitly cast). Rast_get_c_cat() takes a CELL* and Rast_get_cat() takes a void*. Passing the value itself is an error, as is passing a pointer to the wrong numeric type. It appears that calls to G_get_cat() were initially replaced with Rast_get_cat(). This will produce errors due to the wrong number of arguments (Rast_get_cat() also needs a RASTER_MAP_TYPE argument). So it was changed to Rast_get_c_cat(), which has the right number of arguments, but the wrong types, hence the errors. I've fixed these specific cases with r39133, but I can't rule out the possibility that others may have been hidden by casts. xround.c:24: warning: conflicting types for built-in function 'round' Seems to be harmless, though may easily be silenced by, like: Done in r39130, except: /** -round(x) +i_round(x) This is the name of the r.mapcalc function which the file implements, so shouldn't be changed. make[2]: Entering directory `/var/home/ivan/devel/grass-trunk-r39080/raster/r.out.vrml' pv.h:33: warning: 'struct Colors' declared inside parameter list Needs #include grass/raster.h. Fixed in r39131, plus some clean-up. --- raster/r.statistics/method.h 2009-09-08 19:14:04.0 +0700 +++ raster/r.statistics/method.h 2009-09-08 21:43:54.983370151 +0700 @@ -1,3 +1,5 @@ +#include grass/raster.h Fixed in r39132 (also stdio.h for FILE). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
