[GRASS-dev] Handling of Python scripts on MS Windows
Dear list, in my very limited experience, the same Python script for GRASS always runs without problems inside QGIS-GRASS Processing Plugin but sometimes fails in GRASS Enviroment, if other Python are installed on the PC (Stand alone, ARCGIS) Could be QGIS-GRASS Processing Initialization investigated? regards enrico gallo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile limits in Windows 7
2014-02-14 10:10 GMT+01:00 Hamish hamis...@yahoo.com: Hamish wrote: Once done in r.profile, this functionality will be instantly available for MS Windows users (using only GUI). fwiw both stdin and command line are just as available and work in the same way on MS Windows as in Mac and UNIX. That the MS Windows users are not currently getting a command line dos box from the default desktop icon is debatably a mis-feature (there's a long discussion in a trac ticket about that). in very truth, I need r.profile in a Python script and profile= option value is given using a string variable I think stdin is not an option but coordinate_file is OK .. thanks Note that currently when you forget to fill `profile` in GUI and press Run, you will get strange behavior. Now it should be better, you have to leave profile= blank and also add - to the coordinate_file= option. Still possible to get stuck waiting for stdin to close, but much less probable. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.profile limits in Windows 7
Dear list, due to strange misbehaviours, we are doing some stress tests on r.profile under Grass 6.4 and Windows 7 Case A (less interesting, IMHO): r.profile fails with ERROR: G_malloc when the number of pixel queried is more than 1E6 our test: profile lenght: 300km, res=3 OK, res=2 failure ( example a river analysis on a lidar-derived DTM) Case B (more interesting): r.profile fails when profile input is a string larger than 8100 characters (more or less) I suppose the problem comes from a limit of cmd.exe (8191 characters) see [0] Please, consider that using UTM integer coordinates that means only 300 nodes, and this is not so unusual for profile analysis. Probably, using optionally a text file as profile input could solve the problem without refactoring the module... Could be this bug solved in Grass 7? Hope this helps regards enrico gallo [0] http://support.microsoft.com/kb/830473 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.profile + wingrass: missing libfreetype-6.dll - SOLVED
Dear list, in my win7 installation, r.profile is not working in Grass 6.4.3 in GUI nor in CLI The problem is related to missing libfreetype-6.dll I solved copying libfreetype-6.dll in Grass lib directory; see this old message [0] HTH regards, Enrico [0] http://lists.osgeo.org/pipermail/grass-dev/2007-May/031089.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [GRASS-user] Grass SQLite driver math functions
Dear list,
a recent thread on user list was about SQLite and math functions support [1]
The specific problem was well investigated, but the second part of message
(having math support for SQLITE as GRASS default) could be interesting for
future developments. IMHO
2013/9/26 Markus Neteler neteler at osgeo.org
Including SQLite math functions in the standard binary GRASS GIS
distribuition could be a long term solution? I think this is the
choice
SpatialLite did since 2.3 version.
You mean
http://www.gaia-gis.it/gaia-sins/spatialite-sql-3.0.0.html#math
hence
http://www.sqlite.org/contrib
-- extension-functions.c (50.96 KB) contributed by Liam Healy on
2010-02-06 15:45:07
Provide mathematical and string extension functions for SQL queries
using the loadable extensions mechanism. Math: acos, asin, atan, atn2,
atan2, acosh, asinh, atanh, difference, degrees, radians, cos, sin,
tan, cot, cosh, sinh, tanh, coth, exp, log, log10, power, sign, sqrt,
square, ceil, floor, pi. String: replicate, charindex, leftstr,
rightstr, ltrim, rtrim, trim, replace, reverse, proper, padl, padr,
padc, strfilter. Aggregate: stdev, variance, mode, median,
lower_quartile, upper_quartile.
If you refer to this file, then it is more related to (your) SQLite
installation rather than GRASS itself since GRASS just calls SQLite.
best,
Markus
as math library is loaded by SQLite
SELECT load_extension('./libsqlitefunctions.so');
but it's not included in SQLite itself (consistently with SQLite
lightness strategy),
could be this library managed as an optional library when compiling GRASS
GIS
es: --with-sqlite-math
and then loaded by default (if available) when creating vector support db?
As SQLite is the default db, using this option when compiling GRASS for
binary packages, standard users could have a more powerful field editor
using v.db.update.
Please, consider that for many (power)users in Windows using MinGW is
really something arcane...
Do you think this approach might work?
Best regards
Enrico Gallo
[1] http://lists.osgeo.org/pipermail/grass-user/2013-September/068987.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] could r.stream.* become part of GRASS core?
Dear list, as user involved in hydrological analysis, I think r.stream.* modules are essential tools in GRASS GIS. Their availability filled in the empty space left by the Horton Machine / Fruid Turtles library (by prof. Rigon and his fantastic team) no more supported for GRASS GIS. Quality, scientific value and great performances of r.stream.* algorithms it’s out of the question, IMHO Looking in the user mailing list and searching on the web can confirm that many users really appreciate those modules even if some people have trouble with the AddOns installation process. So, could those modules be part of Grass core in the next releases? As part of GRASS GIS core, I think they could be fruitfully become available also in the QGIS GRASS toolbox. Regards, Enrico ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] grass 7.0 - UnboundLocalError: local variable 'kv' referenced before assignment
Hi list,
I just finished installing grass 7.0 from svn (Updated to revision 38527)
on
Ubuntu 9:04, kernel: 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
01:58:03 UTC 2009 x86_64 GNU/Linux
I had no error in configure, nor in make (details attached)
when starting grass70, I get following error:
File /usr/local/bin/grass70, line 862, in module
read_gui()
File /usr/local/bin/grass70, line 201, in read_gui
grass_gui = kv['GRASS_GUI']
UnboundLocalError: local variable 'kv' referenced before assignment
if I start with
grass70 -text option, no error, but I have no way to create location
mapsets from console
I suppose is a Python related error;
I am using
aptitude show python2.6
Package: python2.6
Version: 2.6.2-0ubuntu1
aptitude show python-wxgtk2.8
Package: python-wxgtk2.8
Version: 2.8.9.1-0ubuntu6
many thanks
regards
Enrico Gallo
./configure --with-tcltk-includes=/usr/include/tcl8.5 --with-opengl-includes=/usr/include/GL/ --enable-shared --with-cxx --with-postgres-includes=/usr/include/postgresql/ --with-sqlite --with-odbc --with-python --enable-largefile --with-x --with-motif --with-nls --enable-64bit --with-libs=/usr/lib64 --with-freetype-includes=/usr/include/freetype2/ --with-geos --with-readline
Source directory:/home/gallo/grass7
Build directory: /home/gallo/grass7
Installation directory: ${prefix}/grass-7.0.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler:c++ -g -O2
Building shared libraries: yes
64bit support: yes
OpenGL platform: X11
MacOSX application: no
NVIZ: yes
BLAS support: no
C++ support:yes
Cairo support: yes
DWG support:no
FFMPEG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GEOS support: yes
JPEG support: yes
LAPACK support: no
Large File support (LFS): yes
MySQL support: no
NLS support:yes
ODBC support: yes
OGR support:yes
OpenGL support: yes
PNG support:yes
PostgreSQL support: yes
Python support: yes
Readline support: yes
SQLite support: yes
Tcl/Tk support: yes
wxWidgets support: no
TIFF support: yes
X11 support:yes
Regex support: yes
POSIX thread support: no
GRASS GIS compilation log
-
Started compilation: Mon Jul 27 22:23:02 CEST 2009
--
Errors in:grass70 -text
No errors detected.
--
Finished compilation: Mon Jul 27 22:31:49 CEST 2009
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
