Re: [GRASS-dev] GRASS 7 swig compile warnings and errors

[Glynn Clements]

Markus Neteler wrote:

> I get warnings and errors in swig/python/:

> grass_wrap.c: In function '_wrap_G_vasprintf':
> grass_wrap.c:18166: error: incompatible types in assignment

No idea what's causing this. For me, line 18166 is:

  arg3 = *((va_list *)(argp3));

with arg3 defined as:

  va_list arg3 ;

The others are just warnings.

> Looking around grass_wrap.c:2620

> fprintf(stderr, "sequence length is %d\n", len);

That's debug code, which I have removed (r35480).

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 7 swig compile warnings and errors

[Markus Neteler]

Hi,

I get warnings and errors in swig/python/:

cd swig/python/
make
...
gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include  -g
-Wall  -fno-common -mtune=nocona -m64 -minline-all-stringops   -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2564: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
...
/usr/bin/swig -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-python -module date -shadow date.i
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/datetime.h:18:
Warning(314): 'from' is a python keyword, renaming to '_from'

gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include  -g
-Wall  -fno-common -mtune=nocona -m64 -minline-all-stringops   -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/date_wrap.o -c date_wrap.c
date_wrap.c: In function 'pyseq_to_ptr':
date_wrap.c:2563: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
...
/usr/bin/swig -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include
-python -module grass -shadow grass.i
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:39:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:587:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:591:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:593:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:594:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:595:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:596:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:604:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:607:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:608:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:617:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:618:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:619:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:625:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:626:
Warning(451): Setting a const char * variable may leak memory.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:627:
Warning(451): Setting a const char * variable may leak memory.
gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include  -g
-Wall  -fno-common -mtune=nocona -m64 -minline-all-stringops   -fPIC
-I/usr/include/python2.5 -I/usr/include/python2.5
-DPACKAGE=\""grasslibs"\"
-I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o
OBJ.x86_64-unknown-linux-gnu/grass_wrap.o -c grass_wrap.c
grass_wrap.c: In function 'pyseq_to_ptr':
grass_wrap.c:2620: warning: format '%d' expects type 'int', but
argument 3 has type 'Py_ssize_t'
grass_wrap.c: In function '_wrap_G_vasprintf':
grass_wrap.c:18166: error: incompatible types in assignment
make[1]: *** [OBJ.x86_64-unknown-linux-gnu/grass_wrap.o] Error 1
make[1]: Leaving directory `/home/neteler/grass70/swig/python'
make: *** [default] Error 2


Looking around grass_wrap.c:2620

static void *pyseq_to_ptr(PyObject *input, int data_type)
{
size_t size;
Py_ssize_t len;
...
len = PySequence_Length(input);
array = malloc(len * size);

fprintf(stderr, "sequence length is %d\n", len);
...

swig -version
SWIG Version 1.3.36

Linux mandrivalinux.local 2.6.27.7-server-1mnb #1 SMP Thu Dec 11
17:41:52 EST 2008 x86_64Intel(R) Core(TM)2 CPU T5500  @
1.66GHz GNU/Linux

cat /etc/issue
Mandriva Linux release 2009.0 (Official) for x86_64
Kernel 2.6.27.7-server-1mnb on a Dual-processor x86_64 / \l

Python 2.5.2 (r252:6091

[GRASS-dev] [GRASS GIS] #443: cairo driver: labels are not rendered

[GRASS GIS]

#443: cairo driver: labels are not rendered
--+-
 Reporter:  martinl   |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Display   | Version:  svn-trunk
 Keywords:  cairo |Platform:  All  
  Cpu:  All   |  
--+-
 Cairo driver does not display any labels (PNG driver seems to work). E.g.

 {{{
 d.vect map=geodetic_swwake_...@permanent display=shape,cat
 }}}

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #58: wx version of v.digit relies upon non-portable hacks

[GRASS GIS]

#58: wx version of v.digit relies upon non-portable hacks
--+-
  Reporter:  marisn   |   Owner:  martinl   
  Type:  defect   |  Status:  assigned  
  Priority:  critical |   Milestone:  6.4.0 
 Component:  default  | Version:  6.3.0 RCs 
Resolution:   |Keywords:  wxGUI, v.digit
  Platform:  Unspecified  | Cpu:  Unspecified   
--+-
Comment (by glynn):

 Replying to [comment:11 martinl]:
 > I added local copies of pseudodc.cpp and pseudodc.h to trunk (r35446).
 Please let me know if it works for you.

 It certainly won't work in general, as the Python code (toolbar.py) is
 creating a wx.PseduoDC, not the local version. I daresay that it will work
 if the local copies happen to exactly match the installed version of
 wxPython, but not otherwise.

 IOW, any local copy needs to be SWIG'd and used from Python in place of
 wx.PseudoDC.

 I was looking into this, and got it mostly working, except for the Python-
 ised version of GetIdBounds(). For some reason, SWIG insists upon
 returning an opaque wrapper for wxRect* rather than a wxRect proxy.

 If you can tolerate modifying the code to pass in a new wx.Rect rather
 than expecting GetIdBounds to create and return one, then it's basically
 working.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] build fails on mac osx

[massimo di stefano]

Hi All,

I adjusted the export flag adding lddflag
(i forghet it, sorry, my mistake)
and i added the optimizzation flags -Os)




--
Errors in:
/opt/gis/grass6_devel/vector/v.digit
/opt/gis/grass6_devel/visualization/nviz
--
In case of errors please change into the directory with error and run  
'make'.

If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you  
will

also get errors from anything which uses the library.
--
Finished compilation: Sab 17 Gen 2009 18:51:47 CET
make: *** [default] Error 1


macbook-pro-15-di-sasha:grass6_devel sasha$ cd /opt/gis/grass6_devel/ 
vector/v.digit

macbook-pro-15-di-sasha:v.digit sasha$ make
Makefile:20: warning: overriding commands for target `/opt/gis/ 
grass6_devel/dist.i386-apple-darwin9.6.0/etc/v.digit'
.../../include/Make/Module.make:20: warning: ignoring old commands for  
target `/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/etc/v.digit'
gcc -I/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/include  -arch  
ppc -arch i386 -Os-I/usr/X11/include -I/Library/Frameworks/ 
Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/ 
Library/Frameworks/Tk.framework/PrivateHeaders -I/Library/Frameworks/ 
Tcl.framework/Headers -I/Library/Frameworks/Tk.framework/Headers -I/ 
Library/Frameworks/Tk.framework/PrivateHeaders -I/Library/Frameworks/ 
GDAL.framework/Versions/1.6/Headers-DPACKAGE=\""grassmods"\"  -I/ 
opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/include -o OBJ.i386- 
apple-darwin9.6.0/driver.o -c driver.c

driver.c: In function ‘driver_plot_icon’:
driver.c:54: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c: In function ‘get_window’:
driver.c:61: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c:68: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c: In function ‘driver_open’:
driver.c:101: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c: In function ‘driver_plot_icon’:
driver.c:54: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c: In function ‘get_window’:
driver.c:61: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c:68: error: ‘struct Tcl_Interp’ has no member named ‘result’
driver.c: In function ‘driver_open’:
driver.c:101: error: ‘struct Tcl_Interp’ has no member named ‘result’
lipo: can't figure out the architecture type of: /var/folders/ 
15/15zQj3qeHemLNapL-foqCTI/-Tmp-//cc5VLYAH.out

make: *** [OBJ.i386-apple-darwin9.6.0/driver.o] Error 1
macbook-pro-15-di-sasha:v.digit sasha$


remain the tcl error about v.digit


note regarding nviz, i've these error in may previouse build too,
but nviz works ignoring the error ( i tried both version tcltk and  
wxpython).



regards,
Massimo Di stefano.



epifanio on
irc.freenode.net #grass


---




Il giorno 17/gen/09, alle ore 17:21, grass-dev-requ...@lists.osgeo.org  
ha scritto:



I don't know about the tcltk errors, but for the rest...

On Jan 17, 2009, at 6:20 AM, massimo di stefano wrote:


Hi All

tring to build on osx on a fresh svn checkout :

export CXXFLAGS="-arch ppc -arch i386"
export CFLAGS="-arch ppc -arch i386"


Note: when setting CFLAGS and CXXFLAGS, it overrides the default  
optimization in configure, so you should add optimization to these.   
I suggest -Os for OSX, or that default which is -O2.


see below for missing LDFLAGS note...


then :

open -a textmate include/make/platform.make
BEFORE RUNNNING MAKE i changed the TCLTKLIBS line to: -framework  
Tcl -framework Tk

and i removed render.c

render.c should compile now, though nviz_cmd won't work.  No need to  
delete render.c.



macbook-pro-15-di-sasha:form sasha$ cd /opt/gis/grass6_devel/lib/ 
vector/diglib

macbook-pro-15-di-sasha:diglib sasha$ make
make OBJ.i386-apple-darwin9.6.0/test
echo "==TEST="
==TEST=
gcc -L/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib   -L/ 
usr/local/pgsql/lib/-arch ppc -arch i386   -I/Library/ 
Frameworks/GDAL.framework/Versions/1.6/Headers  -I/opt/gis/ 
grass6_devel/dist.i386-apple-darwin9.6.0/include  -o OBJ.i386-apple- 
darwin9.6.0/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime - 
lz -lgrass_rtree  -lgrass_rtree \

-lgrass_gis -lgrass_datetime -lz 
-lgrass_datetime  -lz
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/ 
lib/libgrass_dig2.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/ 
lib/libgrass_gis.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/ 
lib/libgrass_datetime.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/ 
lib/libgrass_rtree.dylib, file is not of required architecture


When compiling as a universal binary (ppc + i386) you must also set  
LDFLAGS.  The libraries need that for li

[GRASS-dev] grass7 wxgui zoom out not centred on mouse position

[Markus Metz]

In grass7 when zooming out the new display is not centred on the mouse 
position, but on the mirror-position of the mouse position e.g. west is 
not current[0] but current[0] - self.Map.width

I find this confusing, but maybe this is a matter of taste.

The Zoom function is in gui/wxpython/gui_modules/mapdisp_window.py
replacing lines 2231 - 2235 with
   newreg['w'], newreg['n'] = self.Pixel2Cell((x1 - 
self.Map.width * 0.75, \
   y1 - 
self.Map.height * 0.75))
   newreg['e'], newreg['s'] = self.Pixel2Cell((x2 + 
self.Map.width * 0.75, \
   y2 + 
self.Map.height * 0.75))


works for me, the zoomed out display is centred on the previous mouse 
position with zoom factor 2 or the centre of the box drawn when using 
the zoom out button.


Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Michael Barton]

On Jan 16, 2009, at 11:03 PM, Helena Mitasova wrote:


Helena

P.S. I often do grass stuff from home over the net. For grass7  
display through gui, even clicking off or changing
the names of layers is rather time consuming compared to d.rast with  
x0 (I have cable).
Any hints, tricks on how to display maps fast when testing would be  
appreciated.




Helena,

I'm not quite sure what you are referring to here, but will try to  
offer some response. In the wxPython GUI, you can set it to display/ 
render the maps automatically OR turn this off and render the maps  
manually by clicking the show/display button. This is in preferences.  
Also, keep it in the default render mode and NOT "Constrain display  
resolution to computational settings".


I'm sure that things run slower over a network. But on my local  
machine, the display is much faster in the new GUI than in the old GUI  
or d.rast via an xmon. I would think it ought to be faster even over  
the network. The default in the GUI is to render maps for display at  
screen resolution--often much lower than the map resolution. This  
makes the display nearly instantaneous locally. It should also result  
in less info sent over the network when run remotely. However, I don't  
know how you had xmons configured or the current GUI display  
configured over a network.


Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #163: g.transform no longer calculating error for 2nd order transformation

[Michael Barton]

I was able to test a bit.

RMS error reports all 0 for 6 points in a 2nd order transformation.  
But the rectification happens OK. RMS values are reported for a 2nd  
order transformation with more than 6 points.


Michael

On Jan 16, 2009, at 6:39 PM, GRASS GIS wrote:

#163: g.transform no longer calculating error for 2nd order  
transformation
--- 
+

 Reporter:  cmbarton  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  closed
 Priority:  major |   Milestone:  6.4.0
Component:  default   | Version:  svn-develbranch6
Resolution:  fixed |Keywords:  g.transform georectify
 Platform:  All   | Cpu:  Unspecified
--- 
+

Changes (by hamish):

 * status:  reopened => closed
 * resolution:  => fixed

Comment:

Replying to [comment:10 martinl]:

Any reason why this ticket is still open?


last bits should be done now. (r35450 thru r35454)


Hamish

--
Ticket URL: 
GRASS GIS 


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Michael Barton]

On Jan 17, 2009, at 3:04 AM, Markus Metz wrote:




Helena Mitasova wrote:
just a quick note from the first run - it may be better to have SFD  
as default so that the same command as in grass63

gives the same result. E.g. running
g.region rast=elevation
r.watershed elevation thresh=1 accum=accum_10K2  
drain=draindir_10K2 basin=basin_10K2 stream=rivers2


gives an MFD result that some people may consider weird when  
compared with the old r.watershed

(although it is perfectly fine as MFD result)
This is true, the same command gives a different result. But some  
other people may consider the SFD result weird, e.g. with  
elev_lid792_1m in nc_spm_08. As an example imagine a user who wants  
to compare the output of different modules for flow accumulation and  
runs r.terraflow and r.watershed with default settings. With DEMs  
like elev_lid792_1m, MFD is needed to get halfway realistic results,  
and r.watershed with SFD produces here really weird results. I  
haven't found yet a testing dataset where I would prefer the SFD  
results over the MFD results.


So the argument to have SFD as default is that default settings  
produce results identical to the previous version.
The argument to have MFD as default is to keep default settings  
similar to r.terraflow and to use the mode as default that is likely  
to produce the most realistic results (still debatable).


running the same with r.watershed -s gives the same, more "normal"  
looking result.
So people who have r.watershed in scripts and expect/need SFD  
result would need to add -s,

or will be puzzled by the different result.
I'm not that much of a hydrology expert, when would SFD results be  
needed? Should a paragraph be added to the documentation when SFD is  
preferred over MFD?


So whoever has some examples, scripts with r.watershed please run  
it to see whether

it behaves as expected.

Helena



As I understand it, we should not break backward compatibility within  
a release or version. That means that r.watershed should have an SFD  
default for GRASS 6.4 at least and maybe 6.5 (I can't remember if this  
holds between subversion releases) and MFD could be the default for  
GRASS 7.


Michael

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] build fails on mac osx

[William Kyngesburye]

I don't know about the tcltk errors, but for the rest...

On Jan 17, 2009, at 6:20 AM, massimo di stefano wrote:


Hi All

tring to build on osx on a fresh svn checkout :

export CXXFLAGS="-arch ppc -arch i386"
export CFLAGS="-arch ppc -arch i386"


Note: when setting CFLAGS and CXXFLAGS, it overrides the default  
optimization in configure, so you should add optimization to these.  I  
suggest -Os for OSX, or that default which is -O2.


see below for missing LDFLAGS note...


then :

open -a textmate include/make/platform.make
BEFORE RUNNNING MAKE i changed the TCLTKLIBS line to: -framework Tcl  
-framework Tk

and i removed render.c

render.c should compile now, though nviz_cmd won't work.  No need to  
delete render.c.



macbook-pro-15-di-sasha:form sasha$ cd /opt/gis/grass6_devel/lib/ 
vector/diglib

macbook-pro-15-di-sasha:diglib sasha$ make
make OBJ.i386-apple-darwin9.6.0/test
echo "==TEST="
==TEST=
gcc -L/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib   -L/usr/ 
local/pgsql/lib/-arch ppc -arch i386   -I/Library/Frameworks/ 
GDAL.framework/Versions/1.6/Headers  -I/opt/gis/grass6_devel/ 
dist.i386-apple-darwin9.6.0/include  -o OBJ.i386-apple-darwin9.6.0/ 
test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz - 
lgrass_rtree  -lgrass_rtree \

-lgrass_gis -lgrass_datetime -lz 
-lgrass_datetime  -lz
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_dig2.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_gis.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_datetime.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_rtree.dylib, file is not of required architecture


When compiling as a universal binary (ppc + i386) you must also set  
LDFLAGS.  The libraries need that for linking.  Only source compile  
and program linking use C/CXX-FLAGS.


-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly  
what the universe is for and why it is here, it will instantly  
disappear and be replaced by something even more bizarrely  
inexplicable.  There is another theory which states that this has  
already happened.


-Hitchhiker's Guide to the Galaxy 2nd season intro


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Markus Metz]

Helena Mitasova wrote:

[...]
Just run it with elevation in nc_spm. The MFD result is actually more 
realistic because it simulates the existing
lakes but you would have to do additional processing if you need a 
stream network 
Have you looked at the stream segments output (option stream)? That is a 
stream network AFAICT, similar to SFD stream output, and can be 
vectorized with r.thin followed by r.to.vect, same as the SFD stream 
output. Using MFD flow accumulation instead of MFD stream segments to 
get a stream network with different stream segments is however very 
difficult.



[...]
running the same with r.watershed -s gives the same, more "normal" 
looking result.
So people who have r.watershed in scripts and expect/need SFD result 
would need to add -s,

or will be puzzled by the different result.
I'm not that much of a hydrology expert, when would SFD results be 
needed?


when you need to extract vectorized stream network from lower 
resolution data (30-90m) and you need the network
to create a single channel through lakes, SRTM is a good example as is 
the elevation DEM in nc_cpm_08.
See comment above, the stream output does give you a single channel 
through a lake, also with MFD. I tried to make sure the stream segments 
output of MFD can be as easily vectorized as the stream segments output 
of SFD.


| Should a paragraph be added to the documentation when SFD is 
preferred over MFD?


yes, some comments on when to use which option would be helpful.

Helena



So whoever has some examples, scripts with r.watershed please run it 
to see whether

it behaves as expected.

Helena





___
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

[Markus Neteler]

On Fri, Jan 16, 2009 at 1:15 AM, Hamish  wrote:
> 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.

Done in r35461.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Helena Mitasova]

On Jan 17, 2009, at 5:04 AM, Markus Metz wrote:




Helena Mitasova wrote:
just a quick note from the first run - it may be better to have  
SFD as default so that the same command as in grass63

gives the same result. E.g. running
g.region rast=elevation
r.watershed elevation thresh=1 accum=accum_10K2  
drain=draindir_10K2 basin=basin_10K2 stream=rivers2


gives an MFD result that some people may consider weird when  
compared with the old r.watershed

(although it is perfectly fine as MFD result)
This is true, the same command gives a different result. But some  
other people may consider the SFD result weird, e.g. with  
elev_lid792_1m in nc_spm_08. As an example imagine a user who wants  
to compare the output of different modules for flow accumulation  
and runs r.terraflow and r.watershed with default settings. With  
DEMs like elev_lid792_1m, MFD is needed to get halfway realistic  
results, and r.watershed with SFD produces here really weird  
results. I haven't found yet a testing dataset where I would prefer  
the SFD results over the MFD results.


I am talking here about the issues related to including the new  
r.watershed in GRASS64 not the merits
of SFD versus MFD (I have done my share of criticizing SFD for many  
years)
 - people may have scripts, applications where they expect certain  
result and that will be very different
with MFD for certain data. This is perfectly fine with GRASS7 but it  
may be problematic with GRASS64.


Just run it with elevation in nc_spm. The MFD result is actually more  
realistic because it simulates the existing
lakes but you would have to do additional processing if you need a  
stream network (or re-run with -s
or to get a really good result switch from MFD to SFD as your  
modification allows, which is great).


I would like to see the new r.watershed in GRASS64 and not wait for  
GRASS7 but the change should not
create problems for people who have r.watershed included in their  
applications or modeling tools.


So the argument to have SFD as default is that default settings  
produce results identical to the previous version.


that is exactly what I had in mind for GRASS64

The argument to have MFD as default is to keep default settings  
similar to r.terraflow and to use the mode as default that is  
likely to produce the most realistic results (still debatable).


MFD does produce more realistic results - but the problem is that is  
not what people always want
(like the issue of hydrologically "correct" DEMs that fill all the  
depressions changing your wetlands
into straight channels and creating a totally unrealistic hydrology,  
but many GIS textbooks tell you

to do just that)



running the same with r.watershed -s gives the same, more "normal"  
looking result.
So people who have r.watershed in scripts and expect/need SFD  
result would need to add -s,

or will be puzzled by the different result.
I'm not that much of a hydrology expert, when would SFD results be  
needed?


when you need to extract vectorized stream network from lower  
resolution data (30-90m) and you need the network
to create a single channel through lakes, SRTM is a good example as  
is the elevation DEM in nc_cpm_08.


| Should a paragraph be added to the documentation when SFD is  
preferred over MFD?


yes, some comments on when to use which option would be helpful.

Helena



So whoever has some examples, scripts with r.watershed please run  
it to see whether

it behaves as expected.

Helena



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #434: python swig bindings for 7.0 svn noyt working on ubuntu install

[GRASS GIS]

#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
Resolution:|Keywords:  python swig  
  Platform:  Linux | Cpu:  x86-32   
---+
Comment (by neteler):

 I have added Glynn's notes in

 trunk/swig/python/grasspython.dox

 With
 {{{
 make htmldocs
  or
 make pdfdocs
 }}}

 the (limited) documentation can be generated (requires doxygen/graphviz).

 Markus

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] build fails on mac osx

[massimo di stefano]

Hi All

tring to build on osx on a fresh svn checkout :

export CXXFLAGS="-arch ppc -arch i386"
export CFLAGS="-arch ppc -arch i386"
export GDAL_BIN=/Library/Frameworks/GDAL.framework/unix/bin/
export NAD2BIN=/Library/Frameworks/PROJ.framework/Programs/nad2bin


../configure --with-freetype
--with-freetype-includes="/Library/Frameworks/FreeType.framework/unix/ 
include/freetype2 /Library/Frameworks/FreeType.framework/unix/include"

--with-freetype-libs=/Library/Frameworks/FreeType.framework/unix/lib
--with-gdal=/Library/Frameworks/GDAL.framework/Programs/gdal-config
--with-proj --with-proj-includes=/Library/Frameworks/PROJ.framework/ 
unix/include

--with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib
--with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj
--with-jpeg-includes=/Library/Frameworks/UnixImageIO.framework/unix/ 
include

--with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/ 
include

--with-png-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--with-tiff-includes=/Library/Frameworks/UnixImageIO.framework/unix/ 
include

--with-tiff-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib
--without-mysql --with-odbc --with-sqlite
--with-sqlite-libs=/Library/Frameworks/SQLite3.framework/unix/lib
--with-sqlite-includes=/Library/Frameworks/SQLite3.framework/unix/ 
include

--with-fftw-includes=/Library/Frameworks/FFTW3.framework/unix/include
--with-fftw-libs=/Library/Frameworks/FFTW3.framework/unix/lib --with-cxx
--with-opengl=aqua --with-x --without-motif --without-glw
--with-tcltk-includes="/Library/Frameworks/Tcl.framework/Headers / 
Library/Frameworks/Tk.framework/Headers /Library/Frameworks/ 
Tk.framework/PrivateHeaders"

--with-python=/usr/bin/python-config --with-wxwidgets=/usr/bin/wx-config
--with-postgres --with-postgres-includes=/usr/local/pgsql/include/
--with-postgres-libs=/usr/local/pgsql/lib/ --enable-macosx-app
--prefix=/Applications/grass64svn

then :

open -a textmate include/make/platform.make
BEFORE RUNNNING MAKE i changed the TCLTKLIBS line to: -framework Tcl - 
framework Tk

and i removed render.c


make

--
Errors in:
/opt/gis/grass6_devel/lib/form
/opt/gis/grass6_devel/lib/vector/diglib
/opt/gis/grass6_devel/vector/v.digit
/opt/gis/grass6_devel/visualization/nviz
/opt/gis/grass6_devel/visualization/nviz2/cmd
--
In case of errors please change into the directory with error and run  
'make'.

If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you  
will

also get errors from anything which uses the library.
--
Finished compilation: Sab 17 Gen 2009 12:42:54 CET
make: *** [default] Error 1
macbook-pro-15-di-sasha:grass6_devel sasha$ cd /opt/gis/grass6_devel/ 
lib/form

macbook-pro-15-di-sasha:form sasha$ make
gcc -I/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/include  -arch  
ppc -arch i386-fno-common   -DPACKAGE=\""grasslibs"\" -I/usr/X11/ 
include -I/Library/Frameworks/Tcl.framework/Headers -I/Library/ 
Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/ 
PrivateHeaders -I/Library/Frameworks/Tcl.framework/Headers -I/Library/ 
Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tk.framework/ 
PrivateHeaders   -DPACKAGE=\""grasslibs"\"  -I/opt/gis/grass6_devel/ 
dist.i386-apple-darwin9.6.0/include -o OBJ.i386-apple-darwin9.6.0/ 
form.o -c form.c

form.c: In function ‘submit’:
form.c:195: error: ‘struct Tcl_Interp’ has no member named ‘result’
form.c: In function ‘submit’:
form.c:195: error: ‘struct Tcl_Interp’ has no member named ‘result’
lipo: can't figure out the architecture type of: /var/folders/ 
15/15zQj3qeHemLNapL-foqCTI/-Tmp-//ccuoxUul.out

make: *** [OBJ.i386-apple-darwin9.6.0/form.o] Error 1
macbook-pro-15-di-sasha:form sasha$ cd /opt/gis/grass6_devel/lib/ 
vector/diglib

macbook-pro-15-di-sasha:diglib sasha$ make
make OBJ.i386-apple-darwin9.6.0/test
echo "==TEST="
==TEST=
gcc -L/opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib   -L/usr/ 
local/pgsql/lib/-arch ppc -arch i386   -I/Library/Frameworks/ 
GDAL.framework/Versions/1.6/Headers  -I/opt/gis/grass6_devel/dist.i386- 
apple-darwin9.6.0/include  -o OBJ.i386-apple-darwin9.6.0/test test.c - 
lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree  - 
lgrass_rtree \

-lgrass_gis -lgrass_datetime -lz 
-lgrass_datetime  -lz
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_dig2.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_gis.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_datetime.dylib, file is not of required architecture
ld warning: in /opt/gis/grass6_devel/dist.i386-apple-darwin9.6.0/lib/ 
libgrass_rtree.dylib, file

[GRASS-dev] Re: [GRASS GIS] #434: python swig bindings for 7.0 svn noyt working on ubuntu install

[GRASS GIS]

#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
Resolution:|Keywords:  python swig  
  Platform:  Linux | Cpu:  x86-32   
---+
Comment (by glynn):

 Replying to [comment:2 mulligan]:

 > Just updated to rev 35437 and still not getting the python_grass7.py
 files written

 That's correct. There isn't a python_grass7 module any more; instead there
 is a "swig" module with 10 separate sub-modules named:

 utils date grass math proj imagery vector raster display stats

 These can be imported individually with e.g. "import swig.grass", or you
 can import all of them with "import swig" (then use e.g.
 swig.grass.G_gisinit etc), or you can use e.g. "from swig.grass import *"
 to import all names from a module. You can do the latter for multiple
 modules, but AFAIK, there's no way to import names from all sub-modules of
 a module with a single command. OTOH, it wouldn't be hard to add an "all"
 sub-module which does "from  import *" for each submodule.

 Suggestions about the ideal structure for the Python interface are
 welcome. AFAICT, the previous structure was just the quickest way to get
 something working, rather than an explicit design choice.

 > here is the output of sudo make:

 That's a successful compilation.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #58: wx version of v.digit relies upon non-portable hacks

[GRASS GIS]

#58: wx version of v.digit relies upon non-portable hacks
--+-
  Reporter:  marisn   |   Owner:  martinl   
  Type:  defect   |  Status:  assigned  
  Priority:  critical |   Milestone:  6.4.0 
 Component:  default  | Version:  6.3.0 RCs 
Resolution:   |Keywords:  wxGUI, v.digit
  Platform:  Unspecified  | Cpu:  Unspecified   
--+-
Comment (by martinl):

 Replying to [comment:12 kyngchaos]:
 > Those are definitely not needed for OSX, so they should be conditionally
 compiled, even if this is a temporary solution.  The current method of
 "-bundle -undefined dynamic_lookup" for OSX is the proper way to handle
 python extensions in general, which coincidentally takes care of the GDI
 problem.

 That's right, but compiling against local copy of pseudodc should work
 also on Mac and should be harmless. Just to avoid other platform dependent
 conditionalization.

-- 
Ticket URL: 
GRASS GIS 
___
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

[Markus Metz]

Helena Mitasova wrote:


On Jan 17, 2009, at 12:07 AM, Michael Barton wrote:


Markus,

I compiled last night and was able to try this on my Mac this 
evening. No problem at all with the North Carolina elev_lid792_1m 
DEM. Everything ran very fast, of course--even though it runs at 
32bit on the Mac.


As expected, the MFD results look much more realistic than the SFD 
results. Much less linearity and more sinuosity. I can post the 
displays if anyone wants to see them.


No errors from the command.

No errors in compiling.

Seems to work fine on the Mac.

I'm not sure why this can't be backported to develbranch_6 since 
6.4RCx is already out. Does it change any of the r.watershed 
arguments or behavior using the pre-MFD arguments?
Yes, MFD is default, so using the same arguments produces different 
results. See also my reply to Helena:

http://lists.osgeo.org/pipermail/grass-dev/2009-January/041965.html

I would prefer to stay out of the discussion about backporting and leave 
this decision to the long-time developers.


Michael
- it needs to be thoroughly tested on wide range of data
before replacing it. I am trying to get to it too and Markus M has 
done already quite a bit of testing himself. If you can ask Isaac 
and/or whoever has grass7 and is around to test it with different data
(wide range of resolutions, data sources, combinations of parameters, 
integer or float DEMs, latlong, different size and type of depressions 
etc.) that would help.
I fully agree. BTW (repeating myself), the results improve a lot if 
float DEMs are multiplied with 100 or 1000 before used as input.


Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Markus Metz]

Helena Mitasova wrote:
just a quick note from the first run - it may be better to have SFD as 
default so that the same command as in grass63

gives the same result. E.g. running
g.region rast=elevation
r.watershed elevation thresh=1 accum=accum_10K2 
drain=draindir_10K2 basin=basin_10K2 stream=rivers2


gives an MFD result that some people may consider weird when compared 
with the old r.watershed

(although it is perfectly fine as MFD result)
This is true, the same command gives a different result. But some other 
people may consider the SFD result weird, e.g. with elev_lid792_1m in 
nc_spm_08. As an example imagine a user who wants to compare the output 
of different modules for flow accumulation and runs r.terraflow and 
r.watershed with default settings. With DEMs like elev_lid792_1m, MFD is 
needed to get halfway realistic results, and r.watershed with SFD 
produces here really weird results. I haven't found yet a testing 
dataset where I would prefer the SFD results over the MFD results.


So the argument to have SFD as default is that default settings produce 
results identical to the previous version.
The argument to have MFD as default is to keep default settings similar 
to r.terraflow and to use the mode as default that is likely to produce 
the most realistic results (still debatable).


running the same with r.watershed -s gives the same, more "normal" 
looking result.
So people who have r.watershed in scripts and expect/need SFD result 
would need to add -s,

or will be puzzled by the different result.
I'm not that much of a hydrology expert, when would SFD results be 
needed? Should a paragraph be added to the documentation when SFD is 
preferred over MFD?


So whoever has some examples, scripts with r.watershed please run it 
to see whether

it behaves as expected.

Helena


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.watershed

[Helena Mitasova]

just a quick note from the first run - it may be better to have SFD  
as default so that the same command as in grass63

gives the same result. E.g. running
g.region rast=elevation
r.watershed elevation thresh=1 accum=accum_10K2  
drain=draindir_10K2 basin=basin_10K2 stream=rivers2


gives an MFD result that some people may consider weird when compared  
with the old r.watershed

(although it is perfectly fine as MFD result)

running the same with r.watershed -s gives the same, more "normal"  
looking result.
So people who have r.watershed in scripts and expect/need SFD result  
would need to add -s,

or will be puzzled by the different result.

So whoever has some examples, scripts with r.watershed please run it  
to see whether

it behaves as expected.

Helena

P.S. I often do grass stuff from home over the net. For grass7  
display through gui, even clicking off or changing
the names of layers is rather time consuming compared to d.rast with  
x0 (I have cable).
Any hints, tricks on how to display maps fast when testing would be  
appreciated.



On Jan 17, 2009, at 12:07 AM, Michael Barton wrote:


Markus,

I compiled last night and was able to try this on my Mac this  
evening. No problem at all with the North Carolina elev_lid792_1m  
DEM. Everything ran very fast, of course--even though it runs at  
32bit on the Mac.


As expected, the MFD results look much more realistic than the SFD  
results. Much less linearity and more sinuosity. I can post the  
displays if anyone wants to see them.


No errors from the command.

No errors in compiling.

Seems to work fine on the Mac.

I'm not sure why this can't be backported to develbranch_6 since  
6.4RCx is already out. Does it change any of the r.watershed  
arguments or behavior using the pre-MFD arguments?


Michael


On Jan 15, 2009, at 12:39 PM, Markus Metz wrote:




Michael Barton wrote:



On Jan 15, 2009, at 5:22 AM,   
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