Re: [GRASS-dev] 6.4rc1
Hamish wrote: 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. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: 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(?) Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
On Thu, 18 Dec 2008, Martin Landa wrote: Hi, 2008/12/1 Martin Landa landa.mar...@gmail.com: 2008/12/1 Hamish hamis...@yahoo.com: 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. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Martin wrote: 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?]. 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. ho ho ho, Hamish (mostly offline for the next few weeks) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan * d.frame.split? * r.colors.stddev? * v.colors? Yes, please v.colors - no opinion on the others. I added them all. 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. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4rc1
Glynn Clements 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. 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. -- Glynn Clements [EMAIL PROTECTED] ___ 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
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
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
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
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] 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
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
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] 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
