Re: [GRASS-dev] gmath and gpde update
I may found a way to avoid licensing problems or the need to convince the meschach developers to change there license to be compatible with the gpl. We can use parts of the ccmath library. http://freshmeat.net/projects/ccmath/ The ccmath library is licensed under the LGPL, and i hope we don't face any problems with this license? To replace the nr code in grass we need: * a fast lu decomposition with pivoting * computation of eigen values and eigen vectors * singular value decomposition Here a cite from the ccmath matrix library documentation: ### The matrix algebra library contains functions that perform the standard computations of linear algebra. General areas covered are: o Solution of Linear Systems o Matrix Inversion o Eigensystem Analysis o Matrix Utility Operations o Singular Value Decomposition ... o Solving and Inverting Linear Systems: solv - solve a general system of real linear equations. solvps --- solve a real symmetric linear system. solvru --- solve a real right upper triangular linear system. solvtd --- solve a tridiagonal real linear system. minv - invert a general real square matrix. psinv invert a real symmetric matrix. ruinv invert a right upper triangular matrix. ... o Eigensystem Analysis: eigen -- extract all eigen values and vectors of a real symmetric matrix. eigval - extract the eigen values of a real symmetric matrix. evmax -- compute the eigen value of maximum absolute magnitude and its corresponding vector for a symmetric matrix. ... o Singular Value Decomposition: svdval - compute the singular values of a m by n real matrix. sv2val - compute the singular values of a real matrix efficiently for m n. svduv -- compute the singular values and the transformation matrices u and v for a real m by n matrix. sv2uv -- compute the singular values and transformation matrices efficiently for m n. svdu1v - compute the singular values and transformation matrices u1 and v, where u1 overloads the input with the first n column vectors of u. sv2u1v - compute the singular values and the transformation matrices u1 and v efficiently for m n. end ### So the ccmath library provides all the algorithms we need to replace the nr code in grass. I would suggest to extract the needed parts from ccmath and integrate them in the gmath library structure i already created (take a look at the patch i provided). I would suggest an extraction of needed parts because the ccmath library ships a lot of algorithms we don't need and the source code is not well documented and difficult to read. We only need the matrix computation algorithm including documentation and tests. I will keep my sparse matrix solver and matrix-vector algorithm in gmath and extend them, (more sparse matrix and sparse vector operations ... inspired from meschach), to implement in the future a sparse ILU and LU factorisation with minimal fill in. This is needed for huge sparse linear equation systems with bad condition. Such linear equation systems can not be solved with the sparse matrix solver i implemented. Things to be done (very roughly estimated): * extraction of the needed algorithm from ccmath * Implementation of a wrapper around these functions, so a user can replace the grass ccmath extraction with a distribution or self compiled version of the ccmath library. * integration of the documentation and the tests of ccmath matrix into gmath * integration of the ccmath solver in the gmath solver structure. This may result in a modification of the current matrix access methods and a rewrite of the blas 1, 2 and 3 functions i implemented. * replacing the nr code which results in the modification of all dependent gmath code and grass modules * writing tests for all depended modules * improving the grass sparse matrix algorithms and solver Well i guess i will need at least another year to code this. ... So, how about this approach? Any hints, suggestions or criticism? Did i over see an issue? Best regards Soeren 2009/1/15 Glynn Clements gl...@gclements.plus.com Moritz Lennert wrote: I don't really see a problem with it. It's a you do not have the freedom to make this program less free restriction, similar to the restrictions imposed by the GPL. Well, the first paragraphe of the DFSG is: Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software
[GRASS-dev] Re: [GRASS GIS] #398: r.watershed with MFD
#398: r.watershed with MFD --+- Reporter: mmetz| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: reopened Priority: minor| Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): I have submitted a new version of r.watershed to trunk with various changes MFD is fully supported: drainage directions, stream segments, basins, half-basins, RUSLE LS and S factors are all in accordance with MFD flow accumulation. The module is slightly faster and uses a bit less memory. See updated documentation to estimate memory requirements for the ram (all in memory) mode (max 31 MB of RAM for 1 million cells). It is no longer necessary to create a MASK for cells with unknown elevation (NULL values). All cells with unknown elevation (masked or NULL values) are skipped. Zero and negative values are valid elevation values. The color rules generated by the module for flow accumulation have worked for all tests so far and allow visual inspection without manually assigning a color table. I'm using standard deviation and log transform, based on Hamish's (I think) suggestions. Visual output is obsolete but left for comparison. The output drainage direction is slightly changed in case an input map with real depressions was supplied. Previously, real depressions had a drainage direction of -1, but -1 was and is a valid drainage direction indicating a drainage of 45 degree CCW from East towards a cell with unknown elevation. Therefore real depressions have now a drainage direction of 0. As before, if a cell drains due East the drainage direction is 360 degrees, 0 (zero) as drainage direction was unused. RUSLE LS and S factor output maps are now of type DCELL without multiplication by 100. Both factors have always been processed as type double, previously the output maps for the two factors were written out by typecasting from (DCELL * 100) to CELL. Please read the updated documentation before using the new module. Best regards, Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/398#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
Re: [GRASS-dev] v.buffer missing distance argument in GUI
Hi, 2009/1/14 Michael Barton michael.bar...@asu.edu: I can see it 'optional' tab. hm, quite hidden, huh, you cannot see 'optional' tab?? 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] v.buffer missing distance argument in GUI
Hi, 2009/1/15 Markus Neteler nete...@osgeo.org: On Wed, Jan 14, 2009 at 8:41 AM, Martin Landa landa.mar...@gmail.com wrote: BTW, should be devbr6 renamed to 6.5? 6.4.x is used for relbr64. Looking at http://trac.osgeo.org/grass/browser/grass/branches/ - develbranch_6 - ... - releasebranch_6_4 I think it looks ok? I don't find it confusing as it is... Maybe I don't get the point since I am traveling :) Ah, you mean include/version[.in]? It could be done but then all the web stuff/cronjobs needs to be updated which is rather painful. I know, but on the other hand, it should be done;-) BTW, Hamish already started. 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] Re: wingrass640
hi Marco, On Wed, Jan 7, 2009 at 2:18 PM, Marco Pasetti pasetti.ma...@gmail.com wrote: ... The blocking thing is related to the building environment update I planned; in fact, some problems in the GRASS building are generated by some MSYS/MinGW lacks... that's why I decided to replace my current MSYS installation with a fully updated one... and here that's the problem! the MSYS project is poorely documented, and the 1.0.11 version of the istaller, even if available on the repository, is not officially present in the project list... but it seems to be more recent (and bug fixer) than the currently proposed one... even if not fully updated! and the updated are a little be confused (in the way you cannot just unpack the new files because some updates overwrite each other creating messy and buggy installations). I've been reading some articles and mails and I'm figuring how to solve this messy situation... may I suggest to move the build instructions into the Wiki? Currently we have http://grass.osgeo.org/grass63/binary/mswindows/native/#Build GRASS From Source http://trac.osgeo.org/grass/wiki/BuildingOnWindows http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html#GRASS which is rather confusing. A publicly editable document may accelerate the progress to obtain a winGRASS 6.4.0RC2 since more people can add suggestions and update the document to GRASS 6.4.x. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.buffer missing distance argument in GUI
Hi, 2009/1/15 Markus Neteler nete...@osgeo.org: [...] I know, but on the other hand, it should be done;-) BTW, Hamish already started. mhh, maybe things should be sync'ed a bit... perhaps I overlooked the related email(s). http://trac.osgeo.org/grass/changeset/35410 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] Re: wingrass640
Hi Markus, may I suggest to move the build instructions into the Wiki? Currently we have http://grass.osgeo.org/grass63/binary/mswindows/native/#Build GRASS From Source http://trac.osgeo.org/grass/wiki/BuildingOnWindows http://www.webalice.it/marco.pasetti/grass/BuildFromSource.html#GRASS which is rather confusing. A publicly editable document may accelerate the progress to obtain a winGRASS 6.4.0RC2 since more people can add suggestions and update the document to GRASS 6.4.x. OK. I'll consider that. Regards, Marco ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.buffer missing distance argument in GUI
On Thu, Jan 15, 2009 at 12:26 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2009/1/15 Markus Neteler nete...@osgeo.org: On Wed, Jan 14, 2009 at 8:41 AM, Martin Landa landa.mar...@gmail.com wrote: BTW, should be devbr6 renamed to 6.5? 6.4.x is used for relbr64. Looking at http://trac.osgeo.org/grass/browser/grass/branches/ - develbranch_6 - ... - releasebranch_6_4 I think it looks ok? I don't find it confusing as it is... Maybe I don't get the point since I am traveling :) Ah, you mean include/version[.in]? It could be done but then all the web stuff/cronjobs needs to be updated which is rather painful. I know, but on the other hand, it should be done;-) BTW, Hamish already started. mhh, maybe things should be sync'ed a bit... perhaps I overlooked the related email(s). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.buffer missing distance argument in GUI
On Wed, Jan 14, 2009 at 8:41 AM, Martin Landa landa.mar...@gmail.com wrote: BTW, should be devbr6 renamed to 6.5? 6.4.x is used for relbr64. Looking at http://trac.osgeo.org/grass/browser/grass/branches/ - develbranch_6 - ... - releasebranch_6_4 I think it looks ok? I don't find it confusing as it is... Maybe I don't get the point since I am traveling :) Ah, you mean include/version[.in]? It could be done but then all the web stuff/cronjobs needs to be updated which is rather painful. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass-dev Digest, Vol 33, Issue 37
On Jan 15, 2009, at 5:22 AM, grass-dev-requ...@lists.osgeo.org wrote: Date: Thu, 15 Jan 2009 09:39:00 - From: GRASS GIS t...@osgeo.org Subject: [GRASS-dev] Re: [GRASS GIS] #398: r.watershed with MFD To: undisclosed-recipients:; Message-ID: 048.b6a7364e017fd287d20f06fe708ae...@osgeo.org Content-Type: text/plain; charset=utf-8 #398: r.watershed with MFD -- +- Reporter: mmetz| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: reopened Priority: minor| Milestone: 7.0.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified -- +- Comment (by mmetz): I have submitted a new version of r.watershed to trunk with various changes MFD is fully supported: drainage directions, stream segments, basins, half-basins, RUSLE LS and S factors are all in accordance with MFD flow accumulation. The module is slightly faster and uses a bit less memory. See updated documentation to estimate memory requirements for the ram (all in memory) mode (max 31 MB of RAM for 1 million cells). It is no longer necessary to create a MASK for cells with unknown elevation (NULL values). All cells with unknown elevation (masked or NULL values) are skipped. Zero and negative values are valid elevation values. The color rules generated by the module for flow accumulation have worked for all tests so far and allow visual inspection without manually assigning a color table. I'm using standard deviation and log transform, based on Hamish's (I think) suggestions. Visual output is obsolete but left for comparison. The output drainage direction is slightly changed in case an input map with real depressions was supplied. Previously, real depressions had a drainage direction of -1, but -1 was and is a valid drainage direction indicating a drainage of 45 degree CCW from East towards a cell with unknown elevation. Therefore real depressions have now a drainage direction of 0. As before, if a cell drains due East the drainage direction is 360 degrees, 0 (zero) as drainage direction was unused. RUSLE LS and S factor output maps are now of type DCELL without multiplication by 100. Both factors have always been processed as type double, previously the output maps for the two factors were written out by typecasting from (DCELL * 100) to CELL. Please read the updated documentation before using the new module. Best regards, Markus, Can this go into develbranch_6 too? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Test
Another test, disregard... ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #432: scripts/ Makefile bug in i18N string extraction
#432: scripts/ Makefile bug in i18N string extraction
-+--
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Keywords: |Platform: All
Cpu: All |
-+--
As far as I understand the scripts/Makefile process in GRASS 6, the make
pot command does not take into account that the scripts have to be
compiled (see g.parser part below):
{{{
# i.tasscap example: long lines broken for convenience
make[2]: Leaving directory `/home/neteler/grass64/scripts/i.tasscap'
GISRC=/home/neteler/grass64/dist.x86_64-unknown-linux-
gnu/demolocation/.grassrc64 \
GISBASE=/home/neteler/grass64/dist.x86_64-unknown-linux-gnu
PATH=/home/neteler/grass64 \
/dist.x86_64-unknown-linux-gnu/bin:$PATH \
LD_LIBRARY_PATH=/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib:
\
g.parser -t i.tasscap | sed s/\/\/g | sed 's/.*/_()/' \
../../locale/scriptstrings/i.tasscap_to_translate.c ; true
make[1]: Leaving directory `/home/neteler/grass64/scripts/i.tasscap'
}}}
Typically make pot is run on a clean source code tarball, could the
procedure be changed to either trap this or improve it? I am sure that
currently many scripts/ strings are missing from the .po files
(unverified).
Markus
--
Ticket URL: http://trac.osgeo.org/grass/ticket/432
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] Re: grass-dev Digest, Vol 33, Issue 37
Michael Barton wrote: On Jan 15, 2009, at 5:22 AM, grass-dev-requ...@lists.osgeo.org wrote: [...] Comment (by mmetz): I have submitted a new version of r.watershed to trunk with various changes [...] Markus, Can this go into develbranch_6 too? I hope so:-) But I would like to get the new functionality tested by others before it is backported in case I missed something. You mentioned that you are testing the new functionality, and you are using Mac while I use Linux 64bit, so if the new version runs fine and produces proper results on your system that would be encouraging! Below are test scripts for the North Carolina sample dataset nc_spm_08 and the Spearfish dataset spearfish60. You can copy the commands for each dataset into a script and then run the script, after updating to today's version of r.watershed:-) Markus M Testing commands for the elevation map elev_lid792_1m in the North Carolina sample dataset nc_spm_08. SFD and MFD output is strikingly different. g.region rast=elev_lid792_1m # multiply elev_lid792_1m to get millimetres as vertical units r.mapcalc elev_lid792_1m.1mm = round(elev_lid792_1m * 1000.0) # SFD (D8) flow distribution r.watershed elev=elev_lid792_1m.1mm threshold=3000 \ accum=elev_lid792_1m.1mm.acc.sfd drain=elev_lid792_1m.1mm.drain.sfd \ basin=elev_lid792_1m.1mm.basin.sfd stream=elev_lid792_1m.1mm.stream.sfd \ half_b=elev_lid792_1m.1mm.halfb.sfd vis=elev_lid792_1m.1mm.viz.sfd \ length_sl=elev_lid792_1m.1mm.ls.sfd slope_st=elev_lid792_1m.1mm.sls.sfd -s # MFD flow distribution r.watershed elev=elev_lid792_1m.1mm threshold=3000 \ accum=elev_lid792_1m.1mm.acc.mfd drain=elev_lid792_1m.1mm.drain.mfd \ basin=elev_lid792_1m.1mm.basin.mfd stream=elev_lid792_1m.1mm.stream.mfd \ half_b=elev_lid792_1m.1mm.halfb.mfd vis=elev_lid792_1m.1mm.viz.mfd \ length_sl=elev_lid792_1m.1mm.ls.mfd slope_st=elev_lid792_1m.1mm.sls.mfd \ convergence=5 Testing commands for the elevation map elevation.10m in the Spearfish sample dataset spearfish60. Differences between SFD and MFD are mainly in the northern half. g.region rast=elevation.10m # multiply elevation.10m to get centimetres as vertical units r.mapcalc elevation.10m.1cm = round(elevation.10m * 100.0) # SFD (D8) flow distribution r.watershed elev=elevation.10m.1cm threshold=3000 \ accum=elevation.10m.1cm.acc.sfd drain=elevation.10m.1cm.drain.sfd \ basin=elevation.10m.1cm.basin.sfd stream=elevation.10m.1cm.stream.sfd \ half_b=elevation.10m.1cm.halfb.sfd vis=elevation.10m.1cm.viz.sfd \ length_sl=elevation.10m.1cm.ls.sfd slope_st=elevation.10m.1cm.sls.sfd -s # MFD flow distribution r.watershed elev=elevation.10m.1cm threshold=3000 \ accum=elevation.10m.1cm.acc.mfd drain=elevation.10m.1cm.drain.mfd \ basin=elevation.10m.1cm.basin.mfd stream=elevation.10m.1cm.stream.mfd \ half_b=elevation.10m.1cm.halfb.mfd vis=elevation.10m.1cm.viz.mfd \ length_sl=elevation.10m.1cm.ls.mfd slope_st=elevation.10m.1cm.sls.mfd \ convergence=5 Michael ___ 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] [GRASS GIS] #433: Enable (de)selection of map layers in workspace via CTRL or Shift
#433: Enable (de)selection of map layers in workspace via CTRL or Shift -+-- Reporter: epatton | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: trivial | Milestone: 6.4.0 Component: wxGUI| Version: svn-develbranch6 Keywords: workspace, layer, selection |Platform: Linux Cpu: x86-64 | -+-- In the wxgui, one can add a subset of a mapset's map layers to a workspace by using a wildcard search pattern; it would be useful to be able to use the CTRL and/or Shift keys to make more precise selections, where the desired maps do not conform to some common naming convention. -- Ticket URL: http://trac.osgeo.org/grass/ticket/433 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] grass7 compile problems
I am trying to get to test the new r.watershed but I am stuck at
compiling grass7
(I had it working OK without wxwidgets before I updated)
First, the issue with wxWidgets, when I include --with-wxwidgets
I get
checking whether to use wxWidgets... yes
checking for wx-config... /usr/bin/wx-config
checking wxWidgets version... 2.8.9
checking for wx/wxprec.h... yes
checking for wx/wxPython/pseudodc.h... no
configure: error: *** Unable to locate wxWidgets includes.
but I do have it
deliboz%
ls /usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
i_files printfw.h pseudodc.h pyclasses.h pydrawxxx.h pyistream.h
pytree.h swigver.h twoitem.h wxPython.h wxPython_int.h
I tried to add (I don't know what I am doing here)
--with-wxwidgets-includes=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx
--with-wxwidgets-libs=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
but I got the same as above
-
To get at least something running
I did make distclean
svn update
configure, make, make install
with skipped wxWidgets, configure goes through
but make gives error for g.cairocomp (do I need it compiled?)
OBJ.x86_64-unknown-linux-gnu/main.o: In function `init_xlib':
/local/home/helena/grasssvn/grass_trunk/general/g.cairocomp/main.c:118:
undefined reference to `cairo_xlib_surface_get_xrender_format'
collect2: ld returned 1 exit status
and when I try to run any r.* command I get
ERROR: Incompatible library version for module
g., v. commands run OK
any advice would be appreciated,
Helena
-configure without wxwidgets---
GRASS is now configured for: x86_64-unknown-linux-gnu
Source directory:/local/home/helena/grasssvn/grass_trunk
Build directory: /local/home/helena/grasssvn/grass_trunk
Installation directory: ${prefix}/grass-7.0.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -Wall
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
JPEG support: yes
LAPACK support: no
Large File support (LFS): yes
MySQL support: no
NLS support:no
ODBC support: no
OGR support:yes
OpenGL support: yes
PNG support:yes
PostgreSQL support: no
Python support: yes
Readline support: no
SQLite support: yes
Tcl/Tk support: yes
wxWidgets support: no
TIFF support: yes
X11 support:yes
Regex support: yes
POSIX thread support: no
On Wed, 2009-01-07 at 00:44 +, Glynn Clements wrote:
Helena Mitasova wrote:
I am trying to get myself up to date on grass7, especially look at the
wxnviz but although I did make distclean and updated grass trunk
grass7_wxnviz is not found - am I perhaps missing
something in my configure (see below)?
You need --with-wxwidgets for the vdigit and nviz add-ons to the wx
GUI, also for the xganim replacement.
Also, --with-motif no longer exists.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #433: Enable (de)selection of map layers in workspace via CTRL or Shift
#433: Enable (de)selection of map layers in workspace via CTRL or Shift --+- Reporter: epatton | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: trivial | Milestone: 6.4.0 Component: wxGUI| Version: svn-develbranch6 Resolution: |Keywords: workspace, layer, selection Platform: Linux| Cpu: x86-64 --+- Comment (by epatton): Thinking about it a little more, it's just as easy to click the checkbox next to each map rather than use the Control key; but it would be useful to use the Control key in combination with the Shift key to make multiple selections of *blocks* of map layers to load at once. ~ Eric. -- Ticket URL: http://trac.osgeo.org/grass/ticket/433#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] gmath and gpde update
Soeren Gebbert wrote: I may found a way to avoid licensing problems or the need to convince the meschach developers to change there license to be compatible with the gpl. We can use parts of the ccmath library. http://freshmeat.net/projects/ccmath/ The ccmath library is licensed under the LGPL, and i hope we don't face any problems with this license? No. Linking definitely isn't a problem (even proprietary code can link against LGPL libraries). It appears to be LGPL-2, so we can also incorporate code directly into GRASS. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 compile problems
Helena Mitasova wrote:
I am trying to get to test the new r.watershed but I am stuck at
compiling grass7
(I had it working OK without wxwidgets before I updated)
First, the issue with wxWidgets, when I include --with-wxwidgets
I get
checking whether to use wxWidgets... yes
checking for wx-config... /usr/bin/wx-config
checking wxWidgets version... 2.8.9
checking for wx/wxprec.h... yes
checking for wx/wxPython/pseudodc.h... no
configure: error: *** Unable to locate wxWidgets includes.
but I do have it
deliboz%
ls /usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
i_files printfw.h pseudodc.h pyclasses.h pydrawxxx.h pyistream.h
pytree.h swigver.h twoitem.h wxPython.h wxPython_int.h
I tried to add (I don't know what I am doing here)
--with-wxwidgets-includes=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx
--with-wxwidgets-libs=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
but I got the same as above
You could try to add
CPPFLAGS=-I/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/
or
CPPFLAGS=-I/usr/include/wx-2.8/
(location on my system)
without /wx or /wx/wxPython to your configure command. Just a wild guess...
-
To get at least something running
I did make distclean
svn update
configure, make, make install
with skipped wxWidgets, configure goes through
but make gives error for g.cairocomp (do I need it compiled?)
OBJ.x86_64-unknown-linux-gnu/main.o: In function `init_xlib':
/local/home/helena/grasssvn/grass_trunk/general/g.cairocomp/main.c:118:
undefined reference to `cairo_xlib_surface_get_xrender_format'
collect2: ld returned 1 exit status
g.cairocomp is apparently not necessary for other commands to run [1].
[1] http://trac.osgeo.org/grass/ticket/419#comment:8
and when I try to run any r.* command I get
ERROR: Incompatible library version for module
Maybe you have grass libraries of a previous version somewhere in a
system-wide location, e.g. /usr/local/lib, they can conflict with grass
7 and need to be removed.
If grass libraries of a previous version are in e.g.
/usr/local/grass-6.4.0RC2/lib and a file called something like
grass.conf exists in /etc/ld.so.conf.d/ that can also be the cause.
Removing or renaming this file followed by ldconfig could then help.
I hope that helps.
Markus M
g., v. commands run OK
any advice would be appreciated,
Helena
-configure without wxwidgets---
GRASS is now configured for: x86_64-unknown-linux-gnu
Source directory:/local/home/helena/grasssvn/grass_trunk
Build directory: /local/home/helena/grasssvn/grass_trunk
Installation directory: ${prefix}/grass-7.0.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -Wall
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
JPEG support: yes
LAPACK support: no
Large File support (LFS): yes
MySQL support: no
NLS support:no
ODBC support: no
OGR support:yes
OpenGL support: yes
PNG support:yes
PostgreSQL support: no
Python support: yes
Readline support: no
SQLite support: yes
Tcl/Tk support: yes
wxWidgets support: no
TIFF support: yes
X11 support:yes
Regex support: yes
POSIX thread support: no
On Wed, 2009-01-07 at 00:44 +, Glynn Clements wrote:
Helena Mitasova wrote:
I am trying to get myself up to date on grass7, especially look at the
wxnviz but although I did make distclean and updated grass trunk
grass7_wxnviz is not found - am I perhaps missing
something in my configure (see below)?
You need --with-wxwidgets for the vdigit and nviz add-ons to the wx
GUI, also for the xganim replacement.
Also, --with-motif no longer exists.
___
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] grass7 compile problems
I forgot, if gdal is compiled with grass support based on a previous
version, that doesn't work too, you have to compile gdal without grass
support again, then grass7 with gdal support. It's a bit of a hassle but
worth the effort, grass7 is really nice:-)
Markus M
Helena Mitasova wrote:
I am trying to get to test the new r.watershed but I am stuck at
compiling grass7
(I had it working OK without wxwidgets before I updated)
First, the issue with wxWidgets, when I include --with-wxwidgets
I get
checking whether to use wxWidgets... yes
checking for wx-config... /usr/bin/wx-config
checking wxWidgets version... 2.8.9
checking for wx/wxprec.h... yes
checking for wx/wxPython/pseudodc.h... no
configure: error: *** Unable to locate wxWidgets includes.
but I do have it
deliboz%
ls /usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
i_files printfw.h pseudodc.h pyclasses.h pydrawxxx.h pyistream.h
pytree.h swigver.h twoitem.h wxPython.h wxPython_int.h
I tried to add (I don't know what I am doing here)
--with-wxwidgets-includes=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx
--with-wxwidgets-libs=/usr/lib/wxPython-2.8.7.1-gtk2-unicode/include/wx-2.8/wx/wxPython
but I got the same as above
-
To get at least something running
I did make distclean
svn update
configure, make, make install
with skipped wxWidgets, configure goes through
but make gives error for g.cairocomp (do I need it compiled?)
OBJ.x86_64-unknown-linux-gnu/main.o: In function `init_xlib':
/local/home/helena/grasssvn/grass_trunk/general/g.cairocomp/main.c:118:
undefined reference to `cairo_xlib_surface_get_xrender_format'
collect2: ld returned 1 exit status
and when I try to run any r.* command I get
ERROR: Incompatible library version for module
g., v. commands run OK
any advice would be appreciated,
Helena
-configure without wxwidgets---
GRASS is now configured for: x86_64-unknown-linux-gnu
Source directory:/local/home/helena/grasssvn/grass_trunk
Build directory: /local/home/helena/grasssvn/grass_trunk
Installation directory: ${prefix}/grass-7.0.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -Wall
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
JPEG support: yes
LAPACK support: no
Large File support (LFS): yes
MySQL support: no
NLS support:no
ODBC support: no
OGR support:yes
OpenGL support: yes
PNG support:yes
PostgreSQL support: no
Python support: yes
Readline support: no
SQLite support: yes
Tcl/Tk support: yes
wxWidgets support: no
TIFF support: yes
X11 support:yes
Regex support: yes
POSIX thread support: no
On Wed, 2009-01-07 at 00:44 +, Glynn Clements wrote:
Helena Mitasova wrote:
I am trying to get myself up to date on grass7, especially look at the
wxnviz but although I did make distclean and updated grass trunk
grass7_wxnviz is not found - am I perhaps missing
something in my configure (see below)?
You need --with-wxwidgets for the vdigit and nviz add-ons to the wx
GUI, also for the xganim replacement.
Also, --with-motif no longer exists.
___
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] [GRASS GIS] #434: python swig bindings for 7.0 svn noyt working on ubuntu install
#434: python swig bindings for 7.0 svn noyt working on ubuntu install -+-- Reporter: mulligan | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 7.0.0 Component: Python | Version: svn-trunk Keywords: python swig |Platform: Linux Cpu: x86-32 | -+-- I have successfully built grass 7.0 svn today on ubuntu 8.04 and it works fine. I have followed the instructions here http://svn.osgeo.org/grass/grass/trunk/swig/python/README to make the python swig bindings with the output given below The process does noy seem to build the python_grass7.py required and so when i run python test.py as indicated I get this: File test.py, line 8, in module import python_grass7 as g7lib ImportError: No module named python_grass7 Error in sys.excepthook: Traceback (most recent call last): File /usr/lib/python2.5/site-packages/apport_python_hook.py, line 38, in apport_excepthook from apport.packaging_impl import impl as packaging File /usr/lib/python2.5/site-packages/apport/__init__.py, line 1, in module from apport.report import Report File /usr/lib/python2.5/site-packages/apport/report.py, line 14, in module import subprocess, tempfile, os.path, urllib, re, pwd, grp, os, sys File /usr/lib/python2.5/tempfile.py, line 33, in module from random import Random as _Random File /usr/lib/python2.5/random.py, line 43, in module from math import log as _log, exp as _exp, pi as _pi, e as _e, ceil as _ceil File /usr/local/src/grass_trunk/swig/python/math.py, line 7, in module import _math ImportError: No module named _math Original exception was: Traceback (most recent call last): File test.py, line 8, in module import python_grass7 as g7lib ImportError: No module named python_grass7 Many thanks ___ make /usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/etc/python/swig make[1]: Entering directory `/usr/local/src/grass_trunk/swig/python' make[1]: `/usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig' is up to date. make[1]: Leaving directory `/usr/local/src/grass_trunk/swig/python' make /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/_utils.so /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/_date.so /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/_grass.so /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/_math.so /usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/etc/python/swig/_proj.so /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/_imagery.so /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/_vector.so /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/_raster.so /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/_display.so /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/_stats.so /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/utils.py /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/date.py /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/grass.py /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/math.py /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/proj.py /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/imagery.py /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/vector.py /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/raster.py /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/display.py /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/stats.py /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/__init__.py /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/utils.pyc /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/date.pyc /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/grass.pyc /usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/etc/python/swig/math.pyc /usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/etc/python/swig/proj.pyc /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/imagery.pyc /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/vector.pyc /usr/local/src/grass_trunk/dist.i686- pc-linux-gnu/etc/python/swig/raster.pyc /usr/local/src/grass_trunk/dist. i686-pc-linux-gnu/etc/python/swig/display.pyc /usr/local/src/grass_trunk/dist.i686-pc-linux- gnu/etc/python/swig/stats.pyc /usr/local/src/grass_trunk/dist.i686-pc- linux-gnu/etc/python/swig/__init__.pyc
[GRASS-dev] Developing GIS application using Grass and Java on Windows XP
Hi, I need some help for a project with my friends. We need to design a desktop application that takes coordinates of a place and show the area of that coordinates to user. We intend to use java for whole project. In the application we will use some shortest path algorithms and using some user data we will find a path. Anyway, I want to ask something different:After user enters the coordinates we need to get the map of desired area and show it to user. While user is moving the mouse over the map, we need to show the characteristic of the point that mouse arrow is on. I mean if the arrow is over a river we need to inform user that he/she is pointing a water area or the elevation data of where user is pointing. I hope I made it a bit clear. I have no experience over either Grass or GeoTools or OpenGIS. In Grass i know that it has capabilities of using vector and raster data models. Visualization is also Grass's capability as i know. But which platform I will use is a big mystery for us now. Grass is built in C and we want to use Java for our project. Will that be a problem when we need to integrate Grass part to our whole project.Also if i want to develop the application with Grass, should i use Linux distribution? Can i develop on WinXP? What are your suggestions?Thank you... ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] remove replaced modules from trunk
Martin Landa wrote: can we removed deprecated module from trunk? vector/v.buffer vector/v.parallel yes vector/v.delaunay needs to be unwound from v.voronoi. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass7 compile problems
On Thu, Jan 15, 2009 at 10:20 PM, Markus Metz markus.metz.gisw...@googlemail.com wrote: I forgot, if gdal is compiled with grass support based on a previous version, that doesn't work too, you have to compile gdal without grass support again, then grass7 with gdal support. It's a bit of a hassle but worth the effort, grass7 is really nice:-) Won't the GRASS-GDAL plugin solve this? Then you avoid this nightmare... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.buffer missing distance argument in GUI
ML: BTW, should be devbr6 renamed to 6.5? 6.4.x is used for relbr64. MN: Ah, you mean include/version[.in]? It could be done but then all the web stuff/cronjobs needs to be updated which is rather painful. if it breaks all the cron jobs we can switch develbranch_6's VERSION back to 6.4.svn for a while at little cost, and bump it it 6.5 when the time is better. shrug, no rush there as no new major development should be happening in 6.5.svn and '6.4.svn' != '6.4.0.svn'. I guess cron jobs for 6.4 man pages - website etc should now be updated to use releasebranch_6_4 too... Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.buffer missing distance argument in GUI
On Fri, Jan 16, 2009 at 1:29 AM, Hamish hamis...@yahoo.com wrote: ML: BTW, should be devbr6 renamed to 6.5? 6.4.x is used for relbr64. MN: Ah, you mean include/version[.in]? It could be done but then all the web stuff/cronjobs needs to be updated which is rather painful. if it breaks all the cron jobs we can switch develbranch_6's VERSION back to 6.4.svn for a while at little cost, and bump it it 6.5 when the time is better. shrug, no rush there as no new major development should be happening in 6.5.svn and '6.4.svn' != '6.4.0.svn'. Well, current break in a sense that people download 6.4.trunk and 6.5 is inside. But maybe nobody cares. Indeed, all new development in 7 and stabilization in 6. I guess cron jobs for 6.4 man pages - website etc should now be updated to use releasebranch_6_4 too... Once back from traveling I can check that. This would dis-insentivate also the introduction of super new features in GRASS 6 as harder to find :) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] removing more tcltk from trunk
I'm pretty sure that ../lib/gcltk/gronsole.tcl ../lib/gcltk/options.tcl ../lib/gcltk/select.tcl can be safely removed from trunk. ../lib/gcltk/gmsg.tcl is used by nviz, however. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
