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...
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.
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 <hamish_b@yahoo.com>:
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...
On Mon, Dec 1, 2008 at 10:09 AM, Hamish <hamish_b@yahoo.com> wrote:
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...
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...
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...
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)
On Mon, Dec 1, 2008 at 3:44 PM, Helena Mitasova <hmitaso@unity.ncsu.edu> 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.
>>> 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:
<H2>DESCRIPTION</H2>
<EM>d.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),
[...]
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.
> 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...
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.
>> 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.
> > 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.
If you want to use a local copy, you will probably have to rename the
classes to prevent conflicts.
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.
Scratch that. I had assumed that wxPseudoDC was a subclass of wxDC;
unfortunately it isn't. It's a distinct class which just happens to
provide the same methods as wxDC.
That's good enough for Python, but for C++ you can't just treat it as
a wxDC for most operations and call out to Python for the
wxPseudoDC-specific methods (SetId and SetIdBounds). You would have to
invoke *all* methods via Python to eliminate the direct _gdi_.so
dependency.
This probably explains why it isn't part of wxWidgets proper.
d.frame.split: added as d.split.frame in 6.4 (only) as a replacement to
d.split. (for posterity's sake it's nice to have a more useful d.split
for xmons; didn't just expand that as option list was incompatible)
Curious about a grass 7 version using python and FRAME enviro var, but
I don't know much about either of those yet.
r.colors.stddev: the stand-out feature of this script is for differences
maps- it lets you tie the center of the colors scale at zero, even if +/-
sides are not balanced.
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
I remember votes for d.3d and votes again this proposal. Any consensus
before rc1? Personally I have nothing against d.3d. One of the options
would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz
use for nviz_cmd(?)
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
I remember votes for d.3d and votes again this proposal. Any consensus
before rc1? Personally I have nothing against d.3d. One of the options
would to rename d.nviz to something else, e.g. d.nviz.fly and d.nviz
use for nviz_cmd(?)
Glynn was against d.3d because he said he felt all d.* modules should be related to using the Raster library for 2-D drawing. He definitely has a point but d.nviz at least has already broken that convention - there *might* be others in the past but I'm not sure. Personally I tend to think it isn't such a big deal, especially as the "3d" in the name clearly suggests it's different anyway.
d.nviz will wait for 7.0 - is that correct? So we can put off a decision on its name. d.3d.fly, d.3d.flythrough or d.3d.flythru might all be good names.
> > I also added to the list nviz_cmd module. I am not
> > sure about its name. Any ideas?
> >
> > nviz.cmd
>
> I remember votes for d.3d and votes again this proposal.
> Any consensus before rc1?
my 0c vote is for d.3d [for the d.* purists: could the outputted png be
used in the GUI display?].
That depends upon whether the module honours GRASS_PNGFILE,
GRASS_RENDER_IMMEDIATE, GRASS_WIDTH, GRASS_HEIGHT, etc.
E.g. if the GUI selects output to mmap()d BMP files or X Pixmaps, will
the module honour that settting? If it doesn't, it isn't a display
module.
BTW, note that g.pnmcomp only works with PPM/PGM files, not PNG.
maybe m.out.3d? shrug
the user is interested in what the module does, not which engine is used
in the background to do it.
Sure. So long as the module honours all of the various environment
variables (particularly those related to output format), it doesn't
matter how it goes about it. But the chances are that anything which
doesn't use the raster library won't honour those variables. Writing
out a PNG file isn't much use if the GUI is expecting the output to be
placed in PPM/PGM files or in an X Pixmap.
In the worst case, you could write a d.* module which reads an image
file then draws it using R_scaled_raster etc. For vector formats,
that's going to produce sub-standard results compared to native
rendering, but at least the output will end up where it's expected.
