Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window
#1778: Typing in g.region without parameters does not open a g.region window +--- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.region, r.colors, r.mask |Platform: Linux Cpu: x86-64 | +--- Comment(by neteler): Replying to [comment:8 martinl]: Replying to [comment:6 glynn]: This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch. I would call it rather current behaviour. It's probably confusing to the user. Is there any reason why the dialog is not open in this case? For example, from d.erase (on CMD line) you expect that the screen be erased, not that you have to do extra GUI clicking. Or do you refer to g.region? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1778#comment:9 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 GIS] #1778: Typing in g.region without parameters does not open a g.region window
#1778: Typing in g.region without parameters does not open a g.region window +--- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.region, r.colors, r.mask |Platform: Linux Cpu: x86-64 | +--- Comment(by martinl): Replying to [comment:9 neteler]: Replying to [comment:8 martinl]: Replying to [comment:6 glynn]: This is normal. If a command doesn't have any required options, executing the command without parameters will not open a parameter dialog. You can force a parameter dialog to be displayed using the --ui switch. I would call it rather current behaviour. It's probably confusing to the user. Is there any reason why the dialog is not open in this case? For example, from d.erase (on CMD line) you expect that the screen be erased, not that you have to do extra GUI clicking. Or do you refer to g.region? yes, I am referring to `g.region`. There are probably more modules without required parameters which have no expected effect as eg. `d.erase`. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1778#comment:10 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 GIS 7 tech-preview release preparations
Vaclav wrote: * For finding and running a module, user should use the module tree in the search modules tab. Hi, I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2061: Export raster error
#2061: Export raster error +--- Reporter: romanigis | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.3 Component: Raster | Version: 6.4.3 RCs Keywords: raster, export |Platform: MSWindows 7 Cpu: x86-32 | +--- Hi. I am trying to export a raster surface generated from points. There was no problem reading my file (v.in.ascii) in a text format consisting of XYZ columns and setting a region. There was no problem creating a surface from these points (v.surf.rst). The surface is displayed in Map Display and I can navigate in it. The problem occurs when I want to export this surface either as a GeoTiff or ESRI GRID File - r.out.arc/r.out.tiff answers with ERROR: Unable to open file my_surface. Any ideas? Thanks for help Roman Højsager Varinsky -- Ticket URL: http://trac.osgeo.org/grass/ticket/2061 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 GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: menu |Platform: Linux Cpu: Unspecified | -+-- Comment(by wenzeslaus): I added a patch to adjust lmgr frame minimal width according to ideal menu width (attachment:lmgr_width_for_menu.diff). But: * it adjusts minimal size, not the real size, so user cannot make lmgr frame smaller; implement it for the (non-minimal) size is difficult (there are default values and user settings involved) * width is only estimated, I put there some magic constants which worked for en, cs and de on Ubuntu * it should do nothing for English but the locale test fails on some PCs returning None; locale is always fragile It is too complex I think and I'm now not sure if it was worth to even try to write this patch, but since it is written I posted it here. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1742#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] GRASS GIS 7 tech-preview release preparations
Hi, moving the menu discussion to the ticked: http://trac.osgeo.org/grass/ticket/1742#comment:16 On Tue, Aug 27, 2013 at 6:47 AM, Hamish hamis...@yahoo.com wrote: Vaclav wrote: * For finding and running a module, user should use the module tree in the search modules tab. Hi, I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: menu |Platform: Linux Cpu: Unspecified | -+-- Comment(by wenzeslaus): Hamish wrote on ML ([GRASS-dev] GRASS GIS 7 tech-preview release preparations): I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. Look at the 'Search modules' in lmgr. There is a search box but also a tree which you can browse. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) Bit wider is not enough for German, it has to be much bigger. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1742#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
Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: menu |Platform: Linux Cpu: Unspecified | -+-- Comment(by wenzeslaus): I've committed a wider lmgr in r57518. It does nothing for MS Windows, Mac OS X and Ubuntu with Unity (UBUNTU_MENUPROXY properly set). It does nothing if you have some settings, so `mv .grass7 .grass7.1` to test this. I'm don't like it because for English it creates bigger lmgr than needed (on the other platforms) and it is far from being general language- independent. But yes, user can and probably will change it in the settings (save current win layout), but this was possible before the change, too. We can change the constant if needed. It works for German and Ubuntu without global menu. If this is what we want, close the ticked. If it is not, revert r57518. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1742#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] GRASS GIS 7 tech-preview release preparations
So, ok, I committed the fix, but I'm not comfortable with it. Please see the ticked and test the change. http://trac.osgeo.org/grass/ticket/1742#comment:17 On Tue, Aug 27, 2013 at 10:48 AM, Vaclav Petras wenzesl...@gmail.comwrote: Hi, moving the menu discussion to the ticked: http://trac.osgeo.org/grass/ticket/1742#comment:16 On Tue, Aug 27, 2013 at 6:47 AM, Hamish hamis...@yahoo.com wrote: Vaclav wrote: * For finding and running a module, user should use the module tree in the search modules tab. Hi, I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2062: r.fillnulls: Input map has no holes || No NULL cells found
#2062: r.fillnulls: Input map has no holes || No NULL cells found
+---
Reporter: zarch | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Raster | Version: svn-trunk
Keywords: |Platform: Linux
Cpu: x86-64 |
+---
I'm trying to use r.fillnuls to fill a CELL map [0] with four categories.
{{{
G70 g.region rast=tree_rm_small -p # set the region
projection: 99 (Transverse Mercator)
zone: 0
datum: osgb36
ellipsoid: airy
north: 673614.75
south: 672309.75
west: 324718.25
east: 326676
nsres: 0.25
ewres: 0.25
rows: 5220
cols: 7831
cells: 40877820
G70 r.stats -c -l input=tree_rm_small # check that the map has NULLs
100%
1 7612219
2 10576095
3 10678651
4 7654913
* no data 4355942
}}}
But I got:
{{{
G70 r.fillnulls input=tree_rm_small output=tree_rm_small__fill
100%
100%
ERROR: Input map has no holes. Check region settings.
G70 r.fillnulls input=tree_rm_small output=tree_rm_small__fill
method=linear
100%
100%
ERROR: No NULL cells found in input raster.
}}}
How can I solve it? Any hints?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2062
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 GIS] #2062: r.fillnulls: Input map has no holes || No NULL cells found
#2062: r.fillnulls: Input map has no holes || No NULL cells found +--- Reporter: zarch | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: |Platform: Linux Cpu: x86-64 | +--- Comment(by marisn): As fillnulls is using spline interpolator to fill NULL areas, it wouldn't make any sense for category data as You seem to have (i.e. what is category 3.67?). I would rather tend to fix r.fillnulls to not accept CELL map type to prevent users from filling holes in categorized data sets. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2062#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
Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: menu |Platform: Linux Cpu: Unspecified | -+-- Comment(by cmbarton): Replying to [comment:16 wenzeslaus]: Hamish wrote on ML ([GRASS-dev] GRASS GIS 7 tech-preview release preparations): I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. Look at the 'Search modules' in lmgr. There is a search box but also a tree which you can browse. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) Bit wider is not enough for German, it has to be much bigger. I can make the window MUCH wider if I want and then save it so that it opens that wide every time I start the GUI afterwards. So I'm not sure I understand the problem. It seems that the issue is a combination of having long words for menu headings, small displays, and low resolution. Or do I misunderstand? If this is the crux of it, I'm not convinced that we should rework the entire GUI for all other GRASS users in order to deal with that specific problem. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1742#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
Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window
#1778: Typing in g.region without parameters does not open a g.region window +--- Reporter: pvanbosgeo | Owner: grass-dev@… Type: defect | Status: new Priority: critical| Milestone: 7.0.0 Component: Default | Version: svn-trunk Keywords: g.region, r.colors, r.mask |Platform: Linux Cpu: x86-64 | +--- Comment(by glynn): Replying to [comment:8 martinl]: I would call it rather current behaviour. It's probably confusing to the user. Is there any reason why the dialog is not open in this case? If it's valid (so far as the parser can determine) to run a module without providing any options, then it will just get on with it, and not stop to ask for additional options. The real problem here is that there's no way to tell the parser that some options are required when no particular option is required. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1778#comment:11 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] Max OS 10.8: g.gui and DISPLAY
Hi,
Anna and I are trying to compile GRASS 7 on Mac OS 10.8. Although there
were some problems we were able to compile it.
But than we were not able to start GRASS because initialization ended with
the error message about missing X Window system. This comes from
init/grass.py where it checks for DISPLAY variable. The variable is not
set. Do we need it to test it for GRASS7 and Mac OS? Setting to any value
(e.g., export DISPLAY=0) solved the problem.
The second error appears when we try to launch GUI from command line using
g.gui (i.e., the error does not happen during GRASS launch):
wxgui.py: posix_spawn: /Users/...wxpython/wxgui.py2.7: No such file or
directory
Changing the second parameter of G_spawn_ex to a 'python' instead of a
'python source' solved the problem:
Index: g.gui/main.c
===
--- g.gui/main.c(revision 57519)
+++ g.gui/main.c(working copy)
@@ -113,12 +113,13 @@
if (strcmp(type-answer, wxpython) == 0) {
sprintf(progname, %s/etc/gui/wxpython/wxgui.py, G_gisbase());
if (rc_file-answer) {
-G_spawn_ex(getenv(GRASS_PYTHON), progname, progname,
+G_spawn_ex(getenv(GRASS_PYTHON), getenv(GRASS_PYTHON),
progname,
--workspace, rc_file-answer, SF_BACKGROUND, NULL);
}
else {
-G_spawn_ex(getenv(GRASS_PYTHON), progname, progname,
+G_spawn_ex(getenv(GRASS_PYTHON), getenv(GRASS_PYTHON),
progname,
SF_BACKGROUND, NULL);
}
}
We don't understand the code in spawn.c and there are even no comments...
so we are lost.
Anna and Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
