Re: [GRASS-dev] [GRASS GIS] #1105: un-red the trac theme
#1105: un-red the trac theme -+-- Reporter: hamish | Owner: grass-dev@… Type: task | Status: new Priority: minor| Milestone: Website Component: Website | Version: Keywords: trac theme |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by hamish): an example of a nicely themed trac: http://eden.sahanafoundation.org/timeline -- Ticket URL: https://trac.osgeo.org/grass/ticket/1105#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
Re: [GRASS-dev] [GRASS GIS] #2036: Failed watershed analysis on Grass
#2036: Failed watershed analysis on Grass --+- Reporter: mehmeto | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Raster | Version: 6.4.2 Resolution: fixed|Keywords: LFS, r.watershed Platform: MSWindows 7 | Cpu: x86-64 --+- Comment(by mmetz): Replying to [comment:17 hamish]: Replying to [comment:16 mmetz]: In GRASS 6.4.2, r.watershed is IMHO not suitable for production work. How about if you use the -f MDF flag there? Or do you mean more than that? (I take it you mean a methodological improvement, not bug fixes) I mean bug fixes. Some bugs have been fixed only in 6.4.3 and later. Also, r.watershed in G7 uses less memory and is faster. By default, Windows, also a 64 bit Windows, does not have LFS when using the standard API, you need to use the LFS API explicitly. But AFAIU it can be explicitly enabled for libgis, so the programmer only needs to worry about it if the module uses ftell() and fseek() type operations. (and many of the modules already do) It's not so easy for Windows. You need to use the LFS API explicitely, i.e. off64_t, fseeko64(), ftello64, lseek64(), _stati64, etc. Is there a reason that --enable-largefile is not included in relbr_6_4/mswindows/osgeo4w/package.sh's ./configure? Yes, because --enable-largefile has no effect for wingrass 6.x. LFS on Windows is only available for G7, not for G6, independent of any configuration options. mehmeto wrote: So, I undertand that current stable version of Grass for Windows is not a convenient program to do such an analysis on a large map. use the r.watershed -m flag with GRASS 6, then it might be ok. (just take a bit longer) In this case, it is not a matter of processing time, but if the module finishes at al. For trunk, the -m flag could become the default, in order to avoid tickets like this. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2036#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
[GRASS-dev] [GRASS GIS] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager
-+--
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: major| Milestone: 7.0.0
Component: wxGUI| Version: svn-trunk
Keywords: wingrass, vector, attribute |Platform: MSWindows 7
Cpu: x86-64 |
-+--
tested with nc-sample dataset in
{{{
System Info
GRASS version: 7.0.svn
GRASS SVN Revision: 57202
Build Date: 2013-07-18
GIS Library Revision: 56211 (2013-05-12)
GDAL/OGR: 1.9.2
PROJ.4: 4.8.0
GEOS: 3.3.6dev
SQLite: 3.7.10
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
}}}
{{{
g.copy vect=firestations@PERMANENT,myfire
Copy vector firestations@PERMANENT to current mapset as myfire
}}}
open attribute table manager = Add cloumn: addc1, type integer
error message pops up:
{{{
Error in v.db.addcolumn: access denied
}}}
trying the same from the v.db.addcolumn-wxgui
{{{
v.db.addcolumn --verbose map=myfire@user1 columns=addc2 integer
Adding column addc2 to the table
(Sat Jul 20 11:08:52 2013) Command finished (1 sec)
}}}
and from the layer manager-console
{{{
v.db.addcolumn --verbose map=myfire@user1 columns=addc3 integer
Adding column addc3 to the table
(Sat Jul 20 11:10:55 2013) Command finished (0 sec)
}}}
maybe some calling-pythonscript-within-pythonscript issue?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2038
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] compilation of grass on AIX 7.1
On 18 July 2013 20:48, Glynn Clements gl...@gclements.plus.com wrote: gmake[3]: Entering directory `/gpfs/home/neteler/software/grass-7.0.svn/lib/imagery' ... iclass_statistics.c: In function 'I_iclass_free_statistics': iclass_statistics.c:114:5: warning: passing argument 1 of 'G_free' discards 'const' qualifier from pointer target type [enabled by default] The IClass_statistics structure declares name and color as const char *. Either the fields should be changed to char *, or I_iclass_free_statistics() should explicitly cast them in the G_free() calls. Because the `const char *` is generally the right type for string in C, I added the casts to the I_iclass_free_statistics() function. Done in r57232. The signature of G_free is `void G_free(void *)`, so it will trigger warnings with the more strict compiler settings anyway (this can happen e.g. for C++ code). However, I guess that we will not add these casts to grass code. GCC warns me also about format not a string literal and no format arguments. I remember this was once discussed on the ML but I'm not sure what the result was: the call is correct but the G_warning function needs some GCC attributes to specify what it is? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: wingrass, vector, attribute |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by hellik): Replying to [ticket:2038 hellik]: tested with nc-sample dataset in sqlite as db-backend; some debug=3 infos added -- Ticket URL: http://trac.osgeo.org/grass/ticket/2038#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] #2038: wingrass7: v.db.addcolumn fails in attribute table manager
#2038: wingrass7: v.db.addcolumn fails in attribute table manager -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: wingrass, vector, attribute |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by hellik): Replying to [comment:1 hellik]: Replying to [ticket:2038 hellik]: tested with nc-sample dataset in sqlite as db-backend; the same with dbf as db-backend -- Ticket URL: http://trac.osgeo.org/grass/ticket/2038#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-user] grass-addons repository
(changing lists from ubu...@lists.osgeo.org and grass-u...@lists.osgeo.org to grass-dev) On 14 July 2013 17:36, Rashad M mohammedrasha...@gmail.com wrote: I had added grass-addons repository on launchpad[1]. Hi, I wonder what is the right way to addons to the GRASS installation and how then handle this in GRASS. If addons are handled by the packaging system there is no point to handle these addons by g.extension (this is how it works now if I understood correctly). However, in this case addons are not listed in the Addons entry in the Module tree in the Search modules tab in layer manager, since currently only modules available during compilation (using generated XML) and modules in .grass7/addons (using g.extension -a) are added to this tree. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] grass-addons repository
Vaclav wrote: Hi, I wonder what is the right way to addons to the GRASS installation and how then handle this in GRASS. If addons are handled by the packaging system there is no point to handle these addons by g.extension (this is how it works now if I understood correctly). However, in this case addons are not listed in the Addons entry in the Module tree in the Search modules tab in layer manager, since currently only modules available during compilation (using generated XML) and modules in .grass7/addons (using g.extension -a) are added to this tree. for a grass-addon package from e.g. the UbuntuGIS ppa, I'd suggest to treat them as a distribution toolbox and so as any other new toolbox. Then leave it up to the user to avoid re-downloading with g.extension.py. I don't see much point in trying to maintain them in a addon xml registry; or rather I still have a hard time understanding how such a registry deals with the theoretical 50% of addon modules which are personal scripts authored by the user and not in the grass repository. And following that line of thought how a time-frozen selection of addon modules from a PPA should co-exist with both user scripts and live /or updated addon modules direct from svn. Given all that grey area the best I can suggest is to stay as flexible as possible, and so my concern with the xml registry is that it can be quite brittle and so fragile. :-/ but really I have no better idea to suggest. the self- assembling freedesktop.org *.desktop menus + icon files used by Gnome/ KDE/Xfce/LXDE is one way to do it, but having worked with that a bit making the custom menus for the osgeo live disc, I'd observe that it works, but their way is rather abstruse and not very enjoyable to code. You might also explore how GEM + gis.m organized this in GRASS 6 for some ideas. where does the ubuntu recipe install them on the disk now? I am sure it is possible, somehow.. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast3d not launching on windows
Hi,
On Thu, Jul 18, 2013 at 11:30 PM, Hamish hamis...@yahoo.com wrote:
Anna wrote:
I get this error when launching d.rast3d from layer manager
toolbar on Windows.
I fixed it in r57218 [1] but it I was wondering if there is
some better solution?
...
Traceback (most recent call last):
...
Unable to fetch interface description for command 'd.rast3d.py'.
...
[1] http://trac.osgeo.org/grass/changeset/57218
...
os.chdir(...)
Hi,
the Unable to fetch interface description for command error is typically
because the g.parser script-handling module can not find the script that
called it in the system $PATH.
(error message happens in lib/python/script/task.py)
The os.chdir() solution may work on Windows since . is usually in %PATH%
there, but on Unix . is typically not in your path.
I think it's better remove the os.chdir()s and replace them by adding
$GISBASE/etc/gui/scripts/ to the PATH when the wxGUI first starts up.
Going into the grass7 wxGUI's Python shell tab, and import os,
os.getenv('PATH') shows the last entry as etc/gui/scripts/ already.
(tested on linux):-/ so that might not be it.
the command is launched with python executable:
.../python.exe d.rast3d.py
so it seems that it expects the full path to the script and therefore chdir
before it made it work.
$GISBASE/etc/gui/scripts/ is already on the PATH.
On linux the script is installed as d.rast3d without the .py, I guess
it keeps the .py extension on Windows? perhaps check how the script is
called: is e.g. 'd.rast3d.py' requested but 'd.rast3d' found?
there should be d.rast3d.py which is really there so that's not the problem.
So we can keep this solution until someone finds something better.
Thanks,
Anna
Maybe etc/gui/scripts/ needs to be added to PYTHONPATH with
wxscripts = os.path.join(os.getenv('GISBASE'), 'etc', 'gui', 'scripts')
if wxbase not in sys.path:
sys.path.append(wxbase)
?
(probably won't help, but worth a try)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
