[GRASS-dev] Re: [GRASS GIS] #1105: un-red the trac theme

[GRASS GIS]

#1105: un-red the trac theme
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  task |  Status:  new  
 Priority:  minor|   Milestone:  Website  
Component:  Website  | Version:   
 Keywords:  trac theme   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 foreground text color.

 e.g.
 https://trac.osgeo.org/grass/browser/grass/trunk
 https://trac.osgeo.org/grass/wiki

-- 
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] #1105: un-red the trac theme

[GRASS GIS]

#1105: un-red the trac theme
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  task |  Status:  new  
 Priority:  minor|   Milestone:  Website  
Component:  Website  | Version:   
 Keywords:  trac theme   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Which red do you mean?

 Markus

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #1105: un-red the trac theme

[GRASS GIS]

#1105: un-red the trac theme
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  task |  Status:  new  
 Priority:  minor|   Milestone:  Website  
Component:  Website  | Version:   
 Keywords:  trac theme   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 hi,

 the gratuitous use of red may be great for National Geographic Kodachrome
 photography, but in the trac pages it makes my eyes hurt. Any chance to
 switch it back to something less intense?

 seems fairly easy:
  http://trac.edgewall.org/wiki/CookBook/SiteStyleCss


 thanks,
 Hamish

-- 
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] #555: v.in.gpsbabel on wingrass: g.proj error

[GRASS GIS]

#555: v.in.gpsbabel on wingrass: g.proj error
---+
  Reporter:  hamish|   Owner:  grass-...@…
  Type:  defect|  Status:  closed 
  Priority:  minor |   Milestone:  6.4.0  
 Component:  Vector| Version:  6.4.0 RCs  
Resolution:  fixed |Keywords:  wingrass, v.in.gpsbabel, g.proj
  Platform:  MSWindows XP  | Cpu:  x86-32 
---+
Changes (by hamish):

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


Comment:

 tested on XP using last night's 6.5svn nightly build, imports and
 reprojects data fine. I'm not sure why though, there hasn't been a change
 to the g.proj code in a year AFAICT. maybe it was the spawn() code or
 missing manifest?

 still need to retest with 6.4.0, but closing bug as it seems fixed.


 Hamish

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hamish):

 Hi, just tested 6.5svn r42750 nightly build on XP. And I'm back to the
 original error message & exit code 3:
 {{{
 #spearfish
 g.region rast=elevation.10m
 r.terraflow elev=elevation.10m ...

 Assertion failed: nrows * ncols == str->stream_len(), file grass2str.h,
 line 144
 }}}

 the left over .../Temp/STREAM_a02688 file is 10,619,208 bytes.

  * (and .../Temp/ is full of 100+ old tmp*.ppm files at a MB each... :-/
 new ones even after exiting the wxGUI cleanly. now that I look, it's the
 same in /tmp/ in linux)

 {{{
 D2/3: G__read_Cell_head
 D2/3: G__read_Cell_head_array
 D3/3: region item: proj:   1
 D3/3: region item: zone:   13
 D3/3: region item: north:  4928000
 D3/3: region item: south:  4914020
 D3/3: region item: east:   609000
 D3/3: region item: west:   590010
 D3/3: region item: cols:   1899
 D3/3: region item: rows:   1398
 D3/3: region item: e-w resol:  10
 D3/3: region item: n-s resol:  10
 D3/3: region item: format: -1
 D3/3: region item: compressed: 1
 D3/3: create window mapping (1899 columns)
 C:/DOCUME~1/Hamish/LOCALS~1/Temp/STREAM_a02688: length = 9175040
 sizeof(T)=4
 D3/3: nrows=1398   ncols=1899stream_len()=2293760
 C:/DOCUME~1/Hamish/LOCALS~1/Temp/STREAM_a02688: length = 9175040
 sizeof(T)=4
 Assertion failed: nrows * ncols == str->stream_len(), file grass2str.h,
 line 146

 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.
 }}}

 the `length = 9175040` reported by the debug message jumps around every
 time I run it, sometimes it's 0, sometimes its ~55 or so.

  * also often it dies just after the "stats.out file found, renaming."
 message with error code 1. `rm stats.out*` at the msys prompt gets it
 working again.


 Hamish

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hamish):

 Replying to [comment:43 mmetz]:
 > Hmm. Good to hear that it works on CLI. In wxGUI, it might become
 > better once the debug messages have been removed, I had to clear
 > output regularly to get it going again. Too much for the wxGUI
 > output window?

 probably. You'll get similar GUI lockup failures if you try and run vector
 modules while DEBUG=5. It can't handle the incoming message volume. Tcl/Tk
 had the same problem.


 Hamish

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hamish):

 Replying to [comment:40 martinl]:
 > menudata.xml is maintained by
 source:grass/trunk/gui/wxpython/support/update_menudata.py
 > which touches only description and keywords (based on command usage
 > desc).

 thanks, added some notes as
  source:grass/trunk/gui/wxpython/xml/menudata.README

 how to get that into the programmer's manual? doxygen in header comments
 of update_menudata.py?


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] wxnviz and wxdigit problems

[Barton Michael]

I just updated from trunk and tried GRASS 7 and am getting some ugly errors.

On launching a lot of garbage is being dumped to the terminal--Python 
dictionaries for wxnviz and wxdigit (e.g., modeler data). This output also is 
dumped to the terminal and console when any command is run. 

Also, when I try wxnviz it does not work at all. 



Here are some of the errors I get...

Running a command:

===
(Sat Jul 10 07:36:21 2010)  
r.info map=geol...@permanent
{'profile': {'raster2': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 255, 0, 
255)}, 'raster0': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 0, 255, 255)}, 
'raster1': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (255, 0, 0, 255)}, 
'x-axis': {'max': 0, 'type': 'auto', 'log': False, 'min': 0}, 'y-axis': {'max': 
0, 'type': 'auto', 'log': False, 'min': 0}, 'grid': {'color': (200, 200, 200, 
255), 'enabled': True}, 'marker': {'color': (0, 0, 0, 255), 'fill': 
'transparent', 'type': 'triangle', 'legend': u'Segment break', 'size': 2}, 
'font': {'axisSize': 11, 'legendSize': 10, 'titleSize': 12}, 'legend': 
{'enabled': True}}, 'georect': {'symbol': {'color': (0, 0, 255, 255), 'width': 
2}}, 'cmd': {'showType': {'point': {'enabled': True}, 'area': {'enabled': 
True}, 'face': {'enabled': True}, 'centroid': {'enabled': True}, 'line': 
{'enabled': True}, 'boundary': {'enabled': True}}, 'rasterColorTable': 
{'selection': 'rainbow', 'enabled': False}, 'verbosity': {'selection': 
'grassenv'}, 'addNewLayer': {'enabled': True}, 'rasterOpaque': {'enabled': 
False}, 'closeDlg': {'enabled': False}, 'overwrite': {'enabled': False}}, 
'projection': {'statusbar': {'epsg': '', 'proj4': '', 'projFile': 
'/Library/Frameworks/PROJ.framework/Resources/proj/epsg'}, 'format': {'ll': 
'DMS', 'precision': 2}}, 'display': {'outputfont': {'type': 'Courier New', 
'size': '10'}, 'statusbarMode': {'selection': 0}, 'autoZooming': {'enabled': 
False}, 'driver': {'type': 'cairo'}, 'autoRendering': {'enabled': True}, 
'bgcolor': {'color': (255, 255, 255, 255)}, 'compResolution': {'enabled': 
False}, 'font': {'type': '', 'encoding': 'ISO-8859-1'}}, 'nviz': {'light': 
{'color': (255, 255, 255, 255), 'bright': 80, 'pos': {'y': 0.68005, 
'x': 0.68005, 'z': 80}, 'ambient': 20}, 'fringe': {'color': (128, 
128, 128, 255), 'elev': 55}, 'surface': {'shine': {'map': False, 'value': 
60.0}, 'color': {'map': True, 'value': (0, 0, 0, 255)}, 'draw': {'res-coarse': 
9, 'style': 1, 'wire-color': (136, 136, 136, 255), 'mode': 1, 'shading': 1, 
'res-fine': 6}, 'position': {'y': 0, 'x': 0, 'z': 0}}, 'volume': {'color': 
{'map': True, 'value': (0, 0, 0, 255)}, 'shine': {'map': False, 'value': 60.0}, 
'draw': {'shading': 1, 'resolution': 3, 'mode': 0}}, 'vector': {'points': 
{'show': False, 'color': (0, 0, 255, 255), 'height': 0, 'width': 2, 'marker': 
2, 'size': 100}, 'lines': {'color': (0, 0, 255, 255), 'width': 2, 'show': 
False, 'flat': False, 'height': 0}}, 'view': {'persp': {'step': 5, 'value': 
20}, 'pos': {'y': 0.16, 'x': 0.83997}, 'height': {'step': 100}, 
'twist': {'step': 5, 'value': 0}, 'background': {'color': (255, 255, 255, 
255)}, 'z-exag': {'step': 1}}}, 'atm': {'leftDbClick': {'selection': 1}, 
'highlight': {'color': (255, 255, 0, 255), 'width': 2}, 'askOnDeleteRec': 
{'enabled': True}, 'keycolumn': {'value': 'cat'}, 'encoding': {'value': ''}}, 
'general': {'defWindowPos': {'dim': '', 'enabled': False}, 'elementListExpand': 
{'selection': 0}}, 'manager': {'askOnQuit': {'enabled': True}, 
'askOnRemoveLayer': {'enabled': True}, 'changeOpacityLevel': {'enabled': 
False}}, 'vdigit': {'category': {'value': 1}, 'layer': {'value': 1}, 
'queryLength': {'than-selection': 0, 'thresh': 0}, 'breakLines': {'enabled': 
False}, 'selectThresh': {'units': 'screen pixels', 'value': 10}, 
'snapToVertex': {'enabled': False}, 'selectType': {'line': {'enabled': True}, 
'centroid': {'enabled': True}, 'boundary': {'enabled': True}, 'point': 
{'enabled': True}}, 'snapping': {'units': 'screen pixels', 'value': 10}, 
'delRecord': {'enabled': True}, 'addRecord': {'enabled': True}, 'selectInside': 
{'enabled': False}, 'categoryMode': {'selection': 0}, 'saveOnExit': {'enabled': 
False}, 'query': {'box': True, 'selection': 0}, 'addCentroid': {'enabled': 
False}, 'lineWidth': {'units': 'screen pixels', 'value': 2}, 'checkForDupl': 
{'enabled': False}, 'symbol': {'highlightDupl': {'color': (255, 72, 0, 255), 
'enabled': None}, 'boundaryOne': {'color': (0, 255, 0, 255), 'enabled': True}, 
'direction': {'color': (255, 0, 0, 255), 'enabled': False}, 'point': {'color': 
(0, 0, 0, 255), 'enabled': True}, 'area': {'color': (217, 255, 217, 255), 
'enabled': False}, 'vertex': {'color': (255, 20, 147, 255), 'enabled': False}, 
'boundaryNo': {'color': (126, 126, 126, 255), 'enabled': True}, 'highlight': 
{'color': (255, 255, 0, 255), 'enabled': None}, 'centroidOut': {'

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by mmetz):

 Replying to [comment:42 hellik]:
 > Replying to [comment:41 mmetz]:
 > > Replying to [comment:39 hellik]:
 > > >
 > > > I've tried a self compiled Grass65 (r42743) in the osgeo4w-tree on
 my WinVista32-box with nc-sample-dataset started from the gui.
 > > >
 > > >
 > > > {{{
 > > > r.terraflow elevation=elevation filled=ff direction=dd
 accumulation=aa tci=tt memory=800
 > > > }}}
 > > >
 > > > r.terraflow starts and seems to calculate, but after a while, the
 gui freezes
 > >
 > > Try less memory, e.g. default 300 (are there currently 800MB free on
 your vista 32bit box?). Or wait for it complete...
 > >
 > > Markus M
 >
 > the whole wx-gui freezes also with 300mb.
 >
 > starting r.terraflow from the msys-command-line, it's finishing all
 calculations.
 >
 Hmm. Good to hear that it works on CLI. In wxGUI, it might become better
 once the debug messages have been removed, I had to clear output regularly
 to get it going again. Too much for the wxGUI output window?

 Markus M

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hellik):

 Replying to [comment:41 mmetz]:
 > Replying to [comment:39 hellik]:
 > >
 > > I've tried a self compiled Grass65 (r42743) in the osgeo4w-tree on my
 WinVista32-box with nc-sample-dataset started from the gui.
 > >
 > >
 > > {{{
 > > r.terraflow elevation=elevation filled=ff direction=dd accumulation=aa
 tci=tt memory=800
 > > }}}
 > >
 > > r.terraflow starts and seems to calculate, but after a while, the gui
 freezes
 >
 > Try less memory, e.g. default 300 (are there currently 800MB free on
 your vista 32bit box?). Or wait for it complete...
 >
 > Markus M

 the whole wx-gui freezes also with 300mb.

 starting r.terraflow from the msys-command-line, it's finishing all
 calculations.

 Helmut

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GRASS 7 - r3.in.ascii not compiling on Mac

[Glynn Clements]

Barton Michael wrote:

> I just updated from trunk today and tried to compile GRASS 7. 
> 
> r3.in.ascii failed to compile with the following error.
> 
> Michael
> 
> cmb-MBP:r3.in.ascii cmbarton$ make
> : && gcc 
> -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib 
> -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib 
> -arch i386 -arch x86_64 -o 
> /Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/bin/r3.in.ascii
>  OBJ.i386-apple-darwin10.4.0/main.o-lgrass_g3d.7.0.svn 
> -lgrass_gis.7.0.svn   
> Undefined symbols for architecture i386:
>   "_Rast_set_history", referenced from:
>   _main in main.o

This should be fixed by r42746; also for r3.info.

There shouldn't be any other modules with this issue. r3.to.rast is
the only other raster3d module which uses the history functions, and
that already linked against $(RASTERLIB). Any non-raster3d modules
which use the history will have needed to link against $(RASTERLIB) in
order to read/write the history file (G3d has its own versions of
these functions).

This didn't show up on Linux as libgrass_raster is pulled in
automatically by libgrass_g3d, and that's good enough for the GNU
linker. I suspect that it might also have been an issue on Windows.

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

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by mmetz):

 Replying to [comment:39 hellik]:
 >
 > I've tried a self compiled Grass65 (r42743) in the osgeo4w-tree on my
 WinVista32-box with nc-sample-dataset started from the gui.
 >
 >
 > {{{
 > r.terraflow elevation=elevation filled=ff direction=dd accumulation=aa
 tci=tt memory=800
 > }}}
 >
 > r.terraflow starts and seems to calculate, but after a while, the gui
 freezes

 Try less memory, e.g. default 300 (are there currently 800MB free on your
 vista 32bit box?). Or wait for it complete...

 Markus M

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by martinl):

 Replying to [comment:38 hamish]:
 > [aside] can we have a README.howto file in the gui/wxpython/xml/ dir?
 Every time I edit menudata.xml it seems to get overwritten some time later
 by an automated update which I don't see documented anywhere. It sort of
 kills my motivation to work on improving the menus anymore. tx.

 menudata.xml is maintained by
 source:grass/trunk/gui/wxpython/support/update_menudata.py which touches
 only description and keywords (based on command usage desc). Other items
 should be untouched, if not please report it as a bug.

 Martin

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[Markus Metz]

[reply outside tracker because not part of original ticket]

>
> Comment(by hamish):
>
>  Replying to [comment:37 mmetz]:
>  > Well, then we have to change the way modules are presented in the menus.
>
>  [aside] can we have a README.howto file in the gui/wxpython/xml/ dir?
>  Every time I edit menudata.xml it seems to get overwritten some time later
>  by an automated update which I don't see documented anywhere. It sort of
>  kills my motivation to work on improving the menus anymore. tx.
>
Weird. Maybe Martin knows more about it.
>
>
>  > The mingw32 version of stream_len() does not work 100%,
>
>  could you explain for us humble c++ students?
>
Premature conclusion from my side. The patch for stream_len() looks ok
to me, but something went wrong in filldepr.cc lines 131-132:
boundaryStr->seek(0) must be called *after* boundaryStr->stream_len(),
otherwise it did not work for me. The reason is unclear to me, maybe a
combination of gcc 3.4.5 (mingw-vista special r3) and -O2 (grass
default it seems). Or anything else, wild guess is that file stream
handling got mixed up.

>
>  I'd rather you got together with Andrew and/or Laura and co-authored a
>  journal article racing^W comparing the two with the current offerings from
>  the other major proprietary GISs. :-) [seriously]
>
>  http://www.cs.duke.edu/geo*/terraflow/speedup.html
>
In extreme situations, r.terraflow will be faster than r.watershed in
disk swap mode, but not that much I bet. In everyday situations,
r.watershed in disk swap mode can be faster than r.terraflow mainly
because its intermediate files are much smaller and can partially be
cached by the system.

I am interested in a reasonably fast r.watershed that can handle
massive datasets and produces the most realistic results possible.
>
>  Are the core r.watershed algorithms by Ehlschlaeger any more modern? or
>  have you now replaced and upgraded them to 'state of the art'? (whatever
>  that means)

IMHO, the ingenious part is the A* Search as implemented by Chuck
Ehlschlaeger over the whole DEM. My main modification of A* Search was
adding a fast priority queue to the search. There are lots of methods
out there to remove depressions, but in my experience A* Search
produces the most realistic results. There are also lots of flow
distribution algorithms out there, but as for sink treatment, there is
AFAICT no widely accepted golden solution. I settled for something
from 1994 and modified it a bit.
>
>
>  > > > r.terraflow and iostream is written for Linux,
>
>  well I knew a version for Arc existed, so thought it possible,
>  http://wwwmath1.uni-muenster.de:8010/u/jan/TerraFlowExtension/
>
Didn't look at the source code.

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

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hellik):

 Replying to [comment:37 mmetz]:
 [...]
 >
 > IMHO, the debug messages can be removed now, then the fix can be
 backported to 6.4.1 ;-)
 >
 > Markus M

 I've tried a self compiled Grass65 (r42743) in the osgeo4w-tree on my
 WinVista32-box with nc-sample-dataset started from the gui.


 {{{
 r.terraflow elevation=elevation filled=ff direction=dd accumulation=aa
 tci=tt memory=800
 }}}

 r.terraflow starts and seems to calculate, but after a while, the gui
 freezes at the following message in the command output


 {{{
 [...]
 assining preliminary directions
 finding flat areas (plateaus and depressions)
 }}}

 Helmut

-- 
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] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by hamish):

 Replying to [comment:37 mmetz]:
 > Well, then we have to change the way modules are presented in the menus.

 [aside] can we have a README.howto file in the gui/wxpython/xml/ dir?
 Every time I edit menudata.xml it seems to get overwritten some time later
 by an automated update which I don't see documented anywhere. It sort of
 kills my motivation to work on improving the menus anymore. tx.


 > > so it seems that it is prematurely reaching the end of the stream?
 >
 > I never thought I would agree to fix depression filling...

 :)

 > The mingw32 version of stream_len() does not work 100%,

 could you explain for us humble c++ students?

 > workaround in r42734 and r42735. Worksforme now on Windows. On
 > Linux, no difference in results.

 excellent!

 > Can I now put warning messages in r.terraflow that its
 > hydrological algorithms from the late 80ies and early 90ies do
 > not produce very accurate results (its emphasis is on the
 > computational complexity of the algorithms, rather than on
 > modeling realistic flow)?

 I'd rather you got together with Andrew and/or Laura and co-authored a
 journal article racing^W comparing the two with the current offerings from
 the other major proprietary GISs. :-) [seriously]

 http://www.cs.duke.edu/geo*/terraflow/speedup.html


 Are the core r.watershed algorithms by Ehlschlaeger any more modern? or
 have you now replaced and upgraded them to 'state of the art'? (whatever
 that means)


 > > > r.terraflow and iostream is written for Linux,

 well I knew a version for Arc existed, so thought it possible,
  http://wwwmath1.uni-muenster.de:8010/u/jan/TerraFlowExtension/


 > IMHO, the debug messages can be removed now, then the fix can
 > be backported to 6.4.1 ;-)

 I removed the noisiest one, will do the rest after testing tomorrow's
 autobuild. (and of course merge with trunk too)

 If it doesn't change results on UNIX it may as well go into 6.4.0. It
 doesn't matter how risky it is on Windows as it can't be worse than
 before. If you feel there's a risk for breakage on UNIX from this we could
 wait til 6.4.1 for the backport & disable building it in 6.4.0, but we
 should perhaps look over the menus in that case to make sure that the
 emphasis and descriptions are all up to date.


 cheers,
 Hamish

-- 
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] #962: wxGUI crash when moving an undocked map display toolbox

[GRASS GIS]

#962: wxGUI crash when moving an undocked map display toolbox
--+-
 Reporter:  msieczka  |   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  6.4.0
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  toolbar   |Platform:  All  
  Cpu:  x86-64|  
--+-
Changes (by hamish):

  * keywords:  => toolbar
  * platform:  MSWindows Vista => All


Comment:

 just another data point:

 I can reproduce this in 6.4 and 6.5, but I have to try for a minute or two
 first (it's on a rather fast machine, which may help, although I am
 running X tunneled over ssh from it). I got no error message when the
 wxGUI was launched automatically at startup.

 I notice that draging the toolbar is not the most responsive thing once a
 map is loaded. I had to try harder in 6.5, but that might just be chance.

 Running same Debian/stable (lenny) amd64 with python-wxgtk2.8 version
 2.8.7.1-1.1+lenny1 and python 2.5.2-3.


 Also I notice that if I remove or uncheck everything on the list the last
 map standing does not clear from the display window. If I press the erase
 button, the image comes back after I tear-away or reconnect the display
 toolbar.

 I suspect that this is an upstream bug, and there is little we can do
 about it.. but no idea.

 wow, I just restarted grass in text mode and then g.gui from the command
 prompt, and it died after adding a raster map and then a vector map with:
 {{{
 (hamish:10965): Pango-CRITICAL **: pango_break: assertion `attrs != NULL'
 failed
 (hamish:10965): Pango-WARNING **: shaping failure, expect ugly output.
 shape-engine='BasicEngineFc', font='Bitstream Vera Sans 9.9990234375',
 text=''
 }}}

 maybe I should try restarting X now..


 Hamish

-- 
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] #1051: wxgui: SEARCH_PATH corruption

[GRASS GIS]

#1051: wxgui: SEARCH_PATH corruption
---+
  Reporter:  msieczka  |   Owner:  hamish 
  Type:  defect|  Status:  new
  Priority:  minor |   Milestone:  6.4.1  
 Component:  wxGUI | Version:  svn-releasebranch64
Resolution:|Keywords:  mapsets
  Platform:  All   | Cpu:  All
---+
Changes (by hamish):

  * priority:  critical => minor
  * milestone:  6.4.0 => 6.4.1


Comment:

 ok, I've unconfused myself on this and added some new help notes in
 6.5svn+trunk and moved away my off-topic wish to #1104.

 The one last thing to do is to figure out how to grey-out the top
 (current) mapset on the list with `Enable(item, False)`. It's already
 forcibly ticked but this would be more obvious if greyed as well. Any
 tips?

 suggest to backport mapset notes on mapset access rules for 6.4.1.


 Hamish

-- 
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] #1092: WinGrass + R's installation path in %PATH%

[GRASS GIS]

#1092: WinGrass + R's installation path in %PATH%
--+-
  Reporter:  hellik   |   Owner:  grass-...@…  
  Type:  enhancement  |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  wingrass, R  
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by hellik):

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


-- 
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] #1092: WinGrass + R's installation path in %PATH%

[GRASS GIS]

#1092: WinGrass + R's installation path in %PATH%
-+--
 Reporter:  hellik   |   Owner:  grass-...@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  Packaging| Version:  svn-releasebranch64  
 Keywords:  wingrass, R  |Platform:  MSWindows Vista  
  Cpu:  Unspecified  |  
-+--

Comment(by hellik):

 Replying to [comment:4 hellik]:
 > Replying to [comment:3 neteler]:
 > > Looks like a harmless improvement to me which will help the GRASS-R
 users a lot.
 > >
 > > +1 for adding to SVN.
 >
 > done for trunk (r42740) and grass65 (r42742) in a slightly different
 way.
 >
 > Helmut

 and done for grass64svn by r42743

 Helmut

-- 
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] #1092: WinGrass + R's installation path in %PATH%

[GRASS GIS]

#1092: WinGrass + R's installation path in %PATH%
-+--
 Reporter:  hellik   |   Owner:  grass-...@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  Packaging| Version:  svn-releasebranch64  
 Keywords:  wingrass, R  |Platform:  MSWindows Vista  
  Cpu:  Unspecified  |  
-+--

Comment(by hellik):

 Replying to [comment:3 neteler]:
 > Looks like a harmless improvement to me which will help the GRASS-R
 users a lot.
 >
 > +1 for adding to SVN.

 done for trunk (r42740) and grass65 (r42742) in a slightly different way.

 Helmut

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #1104: rfe: easier to read wx map layer list

[GRASS GIS]

#1104: rfe: easier to read wx map layer list
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.1
Component:  wxGUI| Version:  svn-develbranch6 
 Keywords:   |Platform:  All  
  Cpu:  All  |  
-+--
 [moved here from #1051]

 for a while I've had the wish to clean up the list of map layers in the
 main wx display tab as I find it rather cluttering and hard to read.

 perhaps: roads @ PERMANENT, or better: roads (PERMANENT)

 both in the map layer-list and in the list of maps selector. actually just
 omit it in the map-selector pull-down list as it is already given by the
 higher level mapset name heading in the mapset tree (blue text).

 ... and the (opacity: 100%) [:] stuff would be better packed on the right
 edge of the row.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] GRASS 7 - r3.in.ascii not compiling on Mac

[Barton Michael]

I just updated from trunk today and tried to compile GRASS 7. 

r3.in.ascii failed to compile with the following error.

Michael

cmb-MBP:r3.in.ascii cmbarton$ make
: && gcc 
-L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib 
-L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/lib -arch 
i386 -arch x86_64 -o 
/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/bin/r3.in.ascii
 OBJ.i386-apple-darwin10.4.0/main.o-lgrass_g3d.7.0.svn -lgrass_gis.7.0.svn  
 
Undefined symbols for architecture i386:
  "_Rast_set_history", referenced from:
  _main in main.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture x86_64:
  "_Rast_set_history", referenced from:
  _main in main.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
lipo: can't open input file: 
/var/folders/AK/AKpYwDw1EoWI+fFF02nvRk+++TI/-Tmp-//cc8l3PD2.out (No such file 
or directory)
make: *** 
[/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.4.0/bin/r3.in.ascii]
 Error 1
cmb-MBP:r3.in.ascii cmbarton$ cd ..



C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu










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

[GRASS-dev] Re: [GRASS GIS] #1006: r.terraflow fails to stat() stream file on Windows

[GRASS GIS]

#1006: r.terraflow fails to stat() stream file on Windows
---+
 Reporter:  marisn |   Owner:  grass-...@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.0
Component:  Raster | Version:  svn-releasebranch64  
 Keywords:  wingrass, r.terraflow  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by mmetz):

 Replying to [comment:36 hamish]:
 > Replying to [comment:35 mmetz]:
 > > the ability to process large datasets is also covered by other
 modules.
 >
 > I know that, but the (perhaps recently historic) way the modules are
 presented in the menus does not make that clear to users.

 Well, then we have to change the way modules are presented in the menus.
 >
 > from raster/r.terraflow/filldepr.cc
 > {{{
 > /*read next edge*/
 > ae = boundaryStr->read_item(&nextedge);
 > assert(ae == AMI_ERROR_NO_ERROR);
 > }}}
 >
 > which calls include/iostream/mem_stream.h
 > {{{
 > template
 > AMI_err MEM_STREAM::read_item(T **elt)  {
 >
 >   assert(data);
 >
 >   if(curr == dataend) {
 > return AMI_ERROR_END_OF_STREAM;
 >   }
 >   *elt = curr;
 >   curr++;
 >   return AMI_ERROR_NO_ERROR;
 > };
 > }}}
 >
 > so it seems that it is prematurely reaching the end of the stream?

 I never thought I would agree to fix depression filling... The mingw32
 version of stream_len() does not work 100%, workaround in r42734 and
 r42735. Worksforme now on Windows. On Linux, no difference in results. Can
 I now put warning messages in r.terraflow that its hydrological algorithms
 from the late 80ies and early 90ies do not produce very accurate results
 (its emphasis is on the computational complexity of the algorithms, rather
 than on modeling realistic flow)?

 > > r.terraflow and iostream is written for Linux, as also previous
 tickets have
 > > shown, no reason to expect that this is the last problem with Windows.
 > > Please leave it for 6.5 or 7.0.
 >
 > we could easily say the same for all of GRASS.

 Most parts of grass are not giving problems with mingw32, maybe because
 these adhere to C89? C++ doesn't, so problems might be expected here.

 > [snip] even if it is crippled due to LFS (you might say 32bit XP is too
 with its 3.2gb RAM limit),

 You might say that mingw32 is the problem (apart from the msys problems).
 IIUC, stuff compiled on e.g. Windows7 64bit with mingw32 is still 32bit
 and has all the 32bit limits, even if the OS is 64bit. Plus other
 annoyances like sizeof(long) = 4 on Windows 64bit.

 >
 > in pursuit of a technical fix I will add debug messages to mem_stream.h.
 (r42731)

 IMHO, the debug messages can be removed now, then the fix can be
 backported to 6.4.1 ;-)

 Markus M

-- 
Ticket URL: 
GRASS GIS 

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