Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed
Hi,
r.watershed2 changes are now merged into r.watershed1 in SVN devbr6,
trunk. Hopefully without further problems.
Markus Metz wrote:
Actually I wanted to apply the changes of the r.watershed version in
grass-7 to r.watershed2, especially naming of options without points
and uppercase, but didn't get yet to it.
done. ('svn merge' did 99% of the work after devbr6 was solved)
Now that some changes have been applied to r.watershed, maybe this is
sparking some interest in improving some parts here and
there, as suggested by Helena with regard to lsfac and meter to foot
conversion,
ok, but I suggest to do it in grass7. bugfixes can be backported as needed.
also the suggestion of Isaac Ullah to apply a colortable to flow
accumulation that is equivalent to the visual output and remove the
visual option.
see the man page for an example of making a nicely colored accum map
based on standard deviations.
if visual= is to be removed, that should only happen in grass 7.
If I suggest changes to the code again, I will supply diffs in the hope
to support svn change tracking and to avoid the confusion caused by
adding a module that appears new as far as svn is concerned.
the full module probably meant that it got more testers than a patch
would, which is good, but I guess a SVN copy from trunk to grass-addons
would have retained the merge history better. shrug.
for minor changes a patch vs. trunk is definitely the way to go.
in my tests r.watershed(2) is 80 times faster than r.watershed(1). nice!
(35min - 25sec for RAM mode to complete; new SEG mode took 4.5min)
all maps appear the same as old r.watershed.
#spearfish
g.region rast=elevation.10m
time r.watershed -m mem=800 elev=elevation.10m threshold=3000 \
accum=rw2_elev10m.acc \
drain=rw2_elev10m.drain \
basin=rw2_elev10m.basin \
str=rw2_elev10m.stream \
half.b=rw2_elev10m.halfb \
vis=rw2_elev10m.viz \
length.sl=rw2_elev10m.ls \
slope.st=rw2_elev10m.sls
One thing with -m (seg mode).. without -m (ram mode) it takes 166mb RAM.
With -m it took just under what I set memory= to. If I set mem=950 it
used 911mb RAM. Does it not know it only needs ~166mb instead of full
alloc?
Also, if I set -m memory=1200 the r.watershed.seg exits with an error (11):
[same elevation.10m which takes 166mb in RAM mode]
SECTION 1 beginning: Initiating Variables. 6 sections total.
D1/1: segs MB: 1200
D1/1: seg cols: 200
D1/1: seg rows: 200
D1/1:row segments: 7
D1/1: column segments: 10
D1/1: total segments: 70
D1/1: open segments: 419
D1/1: open segments after adjusting: 419
SECTION 1b (of 6): Determining Offmap Flow.
100%
100%
WARNING: category information for [...] missing
[...]
G63 echo $?
11
top reported 1150mb allocated, and I have 2gb so plenty still to spare
and not Linux tearing down a runaway proc AFAICT..
so why the early exit?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] 6.4rc1
Hi, so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to wait on that anymore IMO. bugfixes can continue on until the end. if 6.4 is the last, that means for all of GRASS 6.x so last chances... http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan * d.frame.split? * r.colors.stddev? * v.colors? yes/no? I support all those in 6.x main, but wait for a second vote. as the author my needs are biased.. * v.out.ascii.db - v.out.ascii C code !! * r.pack rewrite using method similar to r.convert (trac84) + tar.gzip? * put together a quick v.to.3d wrapper script? I think all these would be nice, and not super-hard, but currently I lack the time to work on them. release announcement alpha-draft: https://trac.osgeo.org/grass/wiki/Release/6.4.0RC1-News ?, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #381: wxgui: Show attribute data depends on global db connection, not file db connection parameter
#381: wxgui: Show attribute data depends on global db connection, not file db connection parameter --+- Reporter: mlennert | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: wxGUI| Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by mlennert): Just checked again and the issue is actually that the db.connect parameters point to a non-existing database. That is why the db.tables call fails. So, not sure if this is to be considered as a bug. On the other hand, it is an inconvenience, if you have maps linked to different databases in your mapset and might be confusing, when the v.db.connect parameters work. This is why I said: Probably attribute management of a single map and table management for the default database need to be decoupled somehow... But maybe just a more explicit error message (e.g. Please use db.connect to set database parameters), might be helpful. Leaving it open for now to keep it in mind, but if you want to close is as worksforme then that's fine with me. Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/381#comment:4 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] 6.4rc1
Hi, I'm following a bit GRASS 7 development via trac timeline and for me GRASS 7.0 seems to be yet far, far away. Taking into account our development speed, it seems more like 1-2 years till final stable release. Unless magic happens and we get bunch of some die-hard programmes that address all v/r lib issues (and I'm not such kind of person). So - I think, that 6.4.x will not be last 6.x release, as we need to provide new features/bugfixes while 7.0 is not production ready. Competition in GIS area is just heating up and thus we can not say to endusers just wait year or more Also I propose after 6.4 branching change develbranch_6 version to 6.4.80 (we can make some x.x.8x feature releases and x.x.9x betas/rc's) to avoid situation like it's now with 6.4.0 - no more numbers for feature releases/rc's/betas. The point - we should avoid unnecessary branching, as managing branches is taking much of some important person time (yes, Markus, that's You). Yes, I *love* to troll! Don't feed me ;) Maris. 2008/12/1, Hamish [EMAIL PROTECTED]: Hi, so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to wait on that anymore IMO. bugfixes can continue on until the end. if 6.4 is the last, that means for all of GRASS 6.x so last chances... ?, Hamish ___ 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] Re: [GRASS GIS] #382: r.texture NULL or negative value ERROR (possible r.null problem)
#382: r.texture NULL or negative value ERROR (possible r.null problem) -+-- Reporter: khufkens| Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: minor | Milestone: 6.3.1 Component: Raster | Version: 6.3.0 Resolution: worksforme |Keywords: r.texture r.null ERROR null negative values Platform: Linux | Cpu: Unspecified -+-- Changes (by khufkens): * status: new = closed * resolution: = worksforme Comment: Ok, seems that setting g.region makes the error disappear. Sorry, for the inconvencience... Koen -- Ticket URL: https://trac.osgeo.org/grass/ticket/382#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #381: wxgui: Show attribute data depends on global db connection, not file db connection parameter
#381: wxgui: Show attribute data depends on global db connection, not file db connection parameter --+- Reporter: mlennert | Owner: martinl Type: defect | Status: assigned Priority: major| Milestone: 6.4.0 Component: wxGUI| Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by martinl): * status: new = assigned * owner: grass-dev@lists.osgeo.org = martinl * cc: grass-dev@lists.osgeo.org (added) Comment: Should be fixed in r34651 (6.4) and r34652 (7.0). -- Ticket URL: http://trac.osgeo.org/grass/ticket/381#comment:5 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] 6.4rc1
Hi, 2008/12/1 Hamish [EMAIL PROTECTED]: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to wait on that anymore IMO. bugfixes can continue on until the end. if 6.4 is the last, that means for all of GRASS 6.x so last chances... I also vote for creating releasebranch_6_4 within the next days... what about http://trac.osgeo.org/grass/ticket/72 and http://trac.osgeo.org/grass/ticket/58 temporal solution would to include pseudodc.cpp and pseudodc.h to gui/wxpython/vdigit and relay on the given version of wxWidgets. It would be also good to make wx digitizer working under MS Windows. Any winGRASS power users for testing wxGUI? 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
[GRASS-dev] Re: [GRASS GIS] #381: wxgui: Show attribute data depends on global db connection, not file db connection parameter
#381: wxgui: Show attribute data depends on global db connection, not file db connection parameter --+- Reporter: mlennert | Owner: martinl Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: wxGUI| Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by mlennert): * status: assigned = closed * resolution: = fixed Comment: Replying to [comment:5 martinl]: Should be fixed in r34651 (6.4) and r34652 (7.0). Good solution. Thanks ! Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/381#comment:6 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] 6.4rc1
Hi, 2008/12/1 Hamish [EMAIL PROTECTED]: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd ? 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
[GRASS-dev] Re: [GRASS GIS] #90: v.parallel: problems with inside corners
#90: v.parallel: problems with inside corners --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by martinl): * platform: = Unspecified * cpu: = Unspecified Comment: Still actual since we have v.parallel2? -- Ticket URL: http://trac.osgeo.org/grass/ticket/90#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #96: v.surf.bspline broken
#96: v.surf.bspline broken ---+ Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: Raster| Version: unspecified Resolution:|Keywords: Platform: All | Cpu: All ---+ Comment (by martinl): Can be the patch applied in SVN for better testing? -- Ticket URL: http://trac.osgeo.org/grass/ticket/96#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #163: g.transform no longer calculating error for 2nd order transformation
#163: g.transform no longer calculating error for 2nd order transformation ---+ Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect| Status: reopened Priority: major | Milestone: 6.4.0 Component: default | Version: svn-develbranch6 Resolution:|Keywords: g.transform georectify Platform: All | Cpu: Unspecified ---+ Comment (by martinl): Maybe I don't understand the problem fully, is there any reason why this ticket is still open? -- Ticket URL: http://trac.osgeo.org/grass/ticket/163#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] 6.4rc1
On Mon, 1 Dec 2008, Martin Landa wrote: Hi, 2008/12/1 Hamish [EMAIL PROTECTED]: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd What about reviving the d.3d name? Or something that makes the functionality more obvious than nviz.cmd? I kind of think it should be a d.* command because it is really a display command, although different from most of the others... Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
On Dec 1, 2008, at 9:42 AM, Paul Kelly wrote: On Mon, 1 Dec 2008, Martin Landa wrote: Hi, 2008/12/1 Hamish [EMAIL PROTECTED]: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd What about reviving the d.3d name? Or something that makes the functionality more obvious than nviz.cmd? I kind of think it should be a d.* command because it is really a display command, although different from most of the others... calling it d.3d sounds like a good idea (also close to the original sg3d) Helena Paul ___ 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] testing results of r.watershed2 against old r.watershed
Hamish wrote:
Markus Metz wrote:
Actually I wanted to apply the changes of the r.watershed version in
grass-7 to r.watershed2, especially naming of options without points
and uppercase, but didn't get yet to it.
done. ('svn merge' did 99% of the work after devbr6 was solved)
Change option names also for r.watershed.ram and r.watershed.seg? There
are some options in uppercase.
see the man page for an example of making a nicely colored accum map
based on standard deviations.
if visual= is to be removed, that should only happen in grass 7.
Why not setting colors for accum in the module?
in my tests r.watershed(2) is 80 times faster than r.watershed(1). nice!
(35min - 25sec for RAM mode to complete; new SEG mode took 4.5min)
all maps appear the same as old r.watershed.
The speed increase is not static, the new version will be faster the
larger the region (more cells). For somewhat larger regions, the new
module is 1000 times faster.
#spearfish
g.region rast=elevation.10m
time r.watershed -m mem=800 elev=elevation.10m threshold=3000 \
accum=rw2_elev10m.acc \
drain=rw2_elev10m.drain \
basin=rw2_elev10m.basin \
str=rw2_elev10m.stream \
half.b=rw2_elev10m.halfb \
vis=rw2_elev10m.viz \
length.sl=rw2_elev10m.ls \
slope.st=rw2_elev10m.sls
One thing with -m (seg mode).. without -m (ram mode) it takes 166mb RAM.
With -m it took just under what I set memory= to. If I set mem=950 it
used 911mb RAM. Does it not know it only needs ~166mb instead of full
alloc?
It should, but I made a mistake in adjusting the number of open
segments. Please apply the diff attached.
Also, if I set -m memory=1200 the r.watershed.seg exits with an error (11):
[same elevation.10m which takes 166mb in RAM mode]
SECTION 1 beginning: Initiating Variables. 6 sections total.
D1/1: segs MB: 1200
D1/1: seg cols: 200
D1/1: seg rows: 200
D1/1:row segments: 7
D1/1: column segments: 10
D1/1: total segments: 70
D1/1: open segments: 419
D1/1: open segments after adjusting: 419
open segments after adjusting should be 70, fixed with diff.
SECTION 1b (of 6): Determining Offmap Flow.
100%
100%
WARNING: category information for [...] missing
[...]
G63 echo $?
11
top reported 1150mb allocated, and I have 2gb so plenty still to spare
and not Linux tearing down a runaway proc AFAICT..
so why the early exit?
That may be related to the number of open segments exceeding the number
of existing segments. After the changes as in the diff I could not
reproduce that error. Top now reports about 110 MB allocated for
segmented mode, no matter what I specified with memory.
There was also another error in init_vars.c, no memory allocated to char
*mb_opt which could cause a segfault, fixed with diff.
I wonder how many more bugs will surface after more testing...
Markus Metz
--- r.watershed2.orig/seg/init_vars.c 2008-11-29 11:45:15.0 +0100
+++ r.watershed2/seg/init_vars.c 2008-12-01 16:06:16.0 +0100
@@ -11,7 +11,6 @@
int fd, num_cseg_total, num_open_segs;
int seg_rows, seg_cols;
double segs_mb;
-char *mb_opt;
/* int page_block, num_cseg; */
int max_bytes;
@@ -30,6 +29,7 @@
/* dep_slope = 0.0; */
max_bytes = 0;
sides = 8;
+segs_mb = 300;
for (r = 1; r argc; r++) {
if (sscanf(argv[r], el=%[^\n], ele_name) == 1)
ele_flag++;
@@ -61,11 +61,7 @@
ls_flag++;
else if (sscanf(argv[r], ob=%[^\n], ob_name) == 1)
ob_flag++;
- else if (sscanf(argv[r], mb=%[^\n], mb_opt) == 1) {
- if (sscanf(mb_opt, %lf, segs_mb) == 0) {
- segs_mb = 300;
- }
- }
+ else if (sscanf(argv[r], mb=%lf, segs_mb) == 1) ;
else if (sscanf(argv[r], r=%[^\n], ril_name) == 1) {
if (sscanf(ril_name, %lf, ril_value) == 0) {
ril_value = -1.0;
@@ -155,8 +151,10 @@
num_open_segs = segs_mb / 2.86;
G_debug(1, segs MB: %.0f, segs_mb);
-G_debug(1, seg cols: %d, seg_cols);
+G_debug(1, region rows: %d, nrows);
G_debug(1, seg rows: %d, seg_rows);
+G_debug(1, region cols: %d, ncols);
+G_debug(1, seg cols: %d, seg_cols);
num_cseg_total = nrows / SROW + 1;
G_debug(1,row segments:\t%d, num_cseg_total);
@@ -169,8 +167,8 @@
G_debug(1, open segments:\t%d, num_open_segs);
/* nonsense to have more segments open than exist */
-if (num_open_segs nrows)
- num_open_segs = nrows;
+if (num_open_segs num_cseg_total)
+ num_open_segs = num_cseg_total;
G_debug(1, open segments after adjusting:\t%d, num_open_segs);
cseg_open(alt, seg_rows, seg_cols, num_open_segs);
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed
On Dec 1, 2008, at 1:52 AM, [EMAIL PROTECTED] wrote: Date: Mon, 1 Dec 2008 00:52:47 -0800 (PST) From: Hamish [EMAIL PROTECTED] Subject: Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed To: grass-dev@lists.osgeo.org, Markus Metz [EMAIL PROTECTED] Cc: Helena Mitasova [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Hi, r.watershed2 changes are now merged into r.watershed1 in SVN devbr6, trunk. Hopefully without further problems. ... a lot of useful information clipped. Thanks very much Hamish et al for this. Michale ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #387: r.grow.distance, r.random.surface ignores raster MASK
#387: r.grow.distance, r.random.surface ignores raster MASK
-+--
Reporter: marisn | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component: Raster | Version: unspecified
Keywords: |Platform: Unspecified
Cpu: Unspecified |
-+--
When r.grow.distance or r.random.surface are run with enabled raster MASK,
mask is used only to filter out input values but does not affect output
maps (they contain also values in areas hidden by mask).
{{{
g.copy rast=trn.sites,MASK
r.grow.distance input=roads distance=dist_to_road
r.random.surface output=randomized
g.remove rast=MASK
}}}
Display resulting maps - areas OUTSIDE of MASK also contain some values.
In r.random.surface case value in MASKed area is NOT random. As most GRASS
modules will work only in not masked area, it's conterintuitive and
requires additional processing to remove MASKed areas from output maps.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/387
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass_icon_package.zip
Hi Luciano, I tried to download Grass Icon Package but the message apears You don't have permission to access /marco.pasetti/ on this server . Can you send this file to my e-mail address? the file is no longer available, and I sincerely don't remember what was its content. What do you need exactly? MP ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
On Mon, Dec 1, 2008 at 3:44 PM, Helena Mitasova [EMAIL PROTECTED] wrote: On Dec 1, 2008, at 9:42 AM, Paul Kelly wrote: On Mon, 1 Dec 2008, Martin Landa wrote: I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd What about reviving the d.3d name? Or something that makes the functionality more obvious than nviz.cmd? I kind of think it should be a d.* command because it is really a display command, although different from most of the others... calling it d.3d sounds like a good idea (also close to the original sg3d) I like that, too. And command name convention would be also back. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #329: Typo in i.oif.html and wording
#329: Typo in i.oif.html and wording --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: closed Priority: minor| Milestone: 6.4.0 Component: Docs | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by warmerdam): Nikos, Could you let me ([EMAIL PROTECTED]) know if you get this ticket update message? -- Ticket URL: http://trac.osgeo.org/grass/ticket/329#comment:13 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] build without NLS broken
In r34485 there were a bunch of changes to lib/gis/gisinit.c, one of which calls G_init_locale(). However, this is not necessarily defined in locale.c. I'm not really a C guy, but this seemed to fix it for me. For reference, the build fails on an undefined reference to G_init_locale. I tried it on an Ubuntu machine and on OS X. Cheers, David Index: lib/gis/gisinit.c === --- lib/gis/gisinit.c (revision 34654) +++ lib/gis/gisinit.c (working copy) @@ -138,7 +138,9 @@ G_init_logging(); G__init_window(); G__check_for_auto_masking(); +#if defined(HAVE_LIBINTL_H) defined(USE_NLS) G_init_locale(); +#endif G_init_debug(); G_verbose(); G_init_tempfile(); ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1 [nviz.cmd]
ML: I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd PK: What about reviving the d.3d name? Or something that makes the functionality more obvious than nviz.cmd? I kind of think it should be a d.* command because it is really a display command, although different from most of the others... HM: calling it d.3d sounds like a good idea (also close to the original sg3d) MN: I like that, too. And command name convention would be also back. fwiw, here's the description of the old d.3d from GRASS 5's man pages: H2DESCRIPTION/H2 EMd.3d/EM displays three-dimensional graphic images based on GRASS raster map layers. The user identifies the viewing point, the line of sight, a vertical exaggeration factor, the viewing angle (field of view), [...] sounds alright to me. Hamish ___ 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
#163: g.transform no longer calculating error for 2nd order transformation ---+ Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect| Status: reopened Priority: major | Milestone: 6.4.0 Component: default | Version: svn-develbranch6 Resolution:|Keywords: g.transform georectify Platform: All | Cpu: Unspecified ---+ Comment (by hamish): ''I've changed the information in the interactive georectify modules for TclTk? and wxPython.'' has that been changed back to 3,6,10? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/163#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #329: Typo in i.oif.html and wording
#329: Typo in i.oif.html and wording --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: closed Priority: minor| Milestone: 6.4.0 Component: Docs | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): fwiw I attached a file to a bug report I was editing in this trac yesterday, and all the unsubmitted text I had entered in the Comment Box was lost when I hit the back button in firefox (deb/stable). pita to retype it all. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/329#comment:14 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #387: r.grow.distance, r.random.surface ignores raster MASK
#387: r.grow.distance, r.random.surface ignores raster MASK --+- Reporter: marisn | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): note that MASK is only applied when ''reading'' a raster map from disk. http://grass.osgeo.org/grass64/manuals/html64_user/rasterintro.html Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/387#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] 6.4rc1
Martin Landa wrote: I also vote for creating releasebranch_6_4 within the next days... what about http://trac.osgeo.org/grass/ticket/72 It would be also good to make wx digitizer working under MS Windows. Any winGRASS power users for testing wxGUI? yes and http://trac.osgeo.org/grass/ticket/58 (PNG driver off-by-one) yes, it would be great to fix that too. both those should be fixed before 6.4.0, but don't hold rc1 waiting for bugfixes. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed
Markus Metz wrote: Change option names also for r.watershed.ram and r.watershed.seg? There are some options in uppercase. those do not use G_parser() and are not exposed to the user, so not a priority for standardization. Hamish: see the man page for an example of making a nicely colored accum map based on standard deviations. MMetz: Why not setting colors for accum in the module? If you like, but a simple linear color model will not work well: r.univar -e for absolute value of accumulation map: Of the non-null cells: -- n: 2654802 minimum: 1 maximum: 811721 range: 811720 mean: 643.885 mean of absolute values: 643.885 standard deviation: 12230.5 variance: 1.49586e+08 variation coefficient: 1899.49 % sum: 1709387991 1st quartile: 3 median (even number of cells): 6 3rd quartile: 14 90th percentile: 32 ie the bulk of map has little flow, but rivers near outlets have lots, so a statistical method like in the man page example is needed to show the detail, the standard linear color gradients (or even a log one) won't do. in my tests r.watershed(2) is 80 times faster than r.watershed(1). The speed increase is not static, the new version will be faster the larger the region (more cells). For somewhat larger regions, the new module is 1000 times faster. ok, can you suggest better wording for the release announcement? t1000 may as well be infinite, as before the user hit ^C after 2-3 days and so it never finished. So this opens the door to analyzing much bigger (ie modern) datasets; r.terraflow is nice for those, but doesn't provide the catchment basin output maps. With -m it took just under what I set memory= to. If I set mem=950 it used 911mb RAM. Does it not know it only needs ~166mb instead of full alloc? It should, but I made a mistake in adjusting the number of open segments. Please apply the diff attached. tested and applied, thanks. I wonder how many more bugs will surface after more testing... time will tell, but I think it's pretty good, cheers, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #90: v.parallel: problems with inside corners
#90: v.parallel: problems with inside corners
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component: default | Version: unspecified
Resolution: |Keywords:
Platform: Unspecified | Cpu: Unspecified
--+-
Comment (by hamish):
Apparently still an issue. see attached screenshot,
{{{
#spearfish
v.parallel in=railroads dist=500 out=rr_500m
}}}
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/90#comment:5
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #90: v.parallel: problems with inside corners
#90: v.parallel: problems with inside corners --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): v.segment man page example with +500 still has problems. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/90#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] build without NLS broken
David Mahoney wrote: In r34485 there were a bunch of changes to lib/gis/gisinit.c, one of which calls G_init_locale(). However, this is not necessarily defined in locale.c. I'm not really a C guy, but this seemed to fix it for me. For reference, the build fails on an undefined reference to G_init_locale. I tried it on an Ubuntu machine and on OS X. Oops. I have changed lib/gis/locale.c (r34662) so that only the code which depends upon libintl.h is conditionalised, but G_init_locale() is defined unconditionally. This ensures that the setlocale() calls still occur, which is necessary to ensure that e.g. printf(%f) isn't localised. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #387: r.grow.distance, r.random.surface ignores raster MASK
#387: r.grow.distance, r.random.surface ignores raster MASK --+- Reporter: marisn | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: Raster | Version: unspecified Resolution: invalid |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by glynn): * status: new = closed * resolution: = invalid Comment: Replying to [ticket:387 marisn]: When r.grow.distance or r.random.surface are run with enabled raster MASK, mask is used only to filter out input values but does not affect output maps (they contain also values in areas hidden by mask). Display resulting maps - areas OUTSIDE of MASK also contain some values. In r.random.surface case value in MASKed area is NOT random. As most GRASS modules will work only in not masked area, it's conterintuitive and requires additional processing to remove MASKed areas from output maps. Yes. That's how MASK works. That's how it '''always''' works. If you want to mask the '''result''' of an operation, you need to explicitly apply the mask by running e.g. r.resample while the mask is active. -- Ticket URL: http://trac.osgeo.org/grass/ticket/387#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Maris Nartiss wrote: I'm following a bit GRASS 7 development via trac timeline and for me GRASS 7.0 seems to be yet far, far away. Taking into account our development speed, it seems more like 1-2 years till final stable release. Unless magic happens and we get bunch of some die-hard programmes that address all v/r lib issues (and I'm not such kind of person). So - I think, that 6.4.x will not be last 6.x release, as we need to provide new features/bugfixes while 7.0 is not production ready. Competition in GIS area is just heating up and thus we can not say to endusers just wait year or more Alternatively, we can make 6.4 the last 6.x release, start getting 7.0 ready for release, and make 8.0 the really-unstable branch. It all depends upon how much new stuff we want in 7.0. Note that there probably isn't all that much stuff which is broken in 7.0. Most of the things which work in 6.4 but don't work in 7.0 are dead and buried. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Martin Landa wrote: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to wait on that anymore IMO. bugfixes can continue on until the end. if 6.4 is the last, that means for all of GRASS 6.x so last chances... I also vote for creating releasebranch_6_4 within the next days... what about http://trac.osgeo.org/grass/ticket/72 and http://trac.osgeo.org/grass/ticket/58 temporal solution would to include pseudodc.cpp and pseudodc.h to gui/wxpython/vdigit and relay on the given version of wxWidgets. The ideal solution is to figure out how to call the wxPseudoDC method(s) via PyEval_CallObject(). I can't see that it could be so complex as to either hold up the release or to require a hackaround. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Paul Kelly wrote: so what remains todo befor 6.4rc1? IMO lib API and module list should be frozen at that point, which means creating releasebranch_6_4. No need to I also added to the list nviz_cmd module. I am not sure about its name. Any ideas? nviz.cmd What about reviving the d.3d name? Or something that makes the functionality more obvious than nviz.cmd? I kind of think it should be a d.* command because it is really a display command, although different from most of the others... I don't think that it should be a d.* command; that prefix should be reserved for modules which use the raster library. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] build without NLS broken
On Tue, Dec 2, 2008 at 5:45 AM, Glynn Clements [EMAIL PROTECTED] wrote: David Mahoney wrote: In r34485 there were a bunch of changes to lib/gis/gisinit.c, one of which calls G_init_locale(). However, this is not necessarily defined in locale.c. I'm not really a C guy, but this seemed to fix it for me. For reference, the build fails on an undefined reference to G_init_locale. I tried it on an Ubuntu machine and on OS X. Oops. I have changed lib/gis/locale.c (r34662) so that only the code which depends upon libintl.h is conditionalised, but G_init_locale() is defined unconditionally. This ensures that the setlocale() calls still occur, which is necessary to ensure that e.g. printf(%f) isn't localised. Does this affect 6? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
