[GRASS-dev] Re: grass-dev Digest, Vol 32, Issue 39

2008-12-18 Thread Michael Barton



On Dec 18, 2008, at 4:21 AM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org 
 wrote:



Date: Thu, 18 Dec 2008 12:21:17 +0100
From: Martin Landa landa.mar...@gmail.com
Subject: Re: [GRASS-dev] 6.4rc1
To: Hamish hamis...@yahoo.com
Cc: grass-dev grass-dev@lists.osgeo.org
Message-ID:
f8fe65c40812180321x5f978efqda73bb9c9a67e...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

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(?)


d.* commands produce a visualization in a display window. d.nviz seems  
the obvious one, though I don't have any objections to d.3d either.  
The current d.nviz is really intended to create a fly-through path for  
nviz--interactively or non-interactively. It won't work interactively  
on anything but an xterm, so d.nviz is kind of a misnomer. We don't  
have a prefix for 3D modules, thought maybe we should think of one.  
Lacking that, nviz.flythough is the most accurate description, or  
perhaps v.nviz.flythrough since you set (sort of) vector points to  
create the path.


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


Re: [GRASS-dev] Re: grass-dev Digest, Vol 32, Issue 39

2008-12-18 Thread Paul Kelly

On Thu, 18 Dec 2008, Michael Barton wrote:

On Dec 18, 2008, at 4:21 AM, grass-dev-requ...@lists.osgeo.org 
grass-dev-requ...@lists.osgeo.org wrote:



Date: Thu, 18 Dec 2008 12:21:17 +0100
From: Martin Landa landa.mar...@gmail.com
Subject: Re: [GRASS-dev] 6.4rc1
To: Hamish hamis...@yahoo.com
Cc: grass-dev grass-dev@lists.osgeo.org
Message-ID:
f8fe65c40812180321x5f978efqda73bb9c9a67e...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

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(?)


d.* commands produce a visualization in a display window. d.nviz seems the 
obvious one, though I don't have any objections to d.3d either. The current 
d.nviz is really intended to create a fly-through path for 
nviz--interactively or non-interactively. It won't work interactively on 
anything but an xterm, so d.nviz is kind of a misnomer. We don't have a 
prefix for 3D modules, thought maybe we should think of one. Lacking that, 
nviz.flythough is the most accurate description, or perhaps v.nviz.flythrough 
since you set (sort of) vector points to create the path.


My only objection to that is that nviz is not at all obvious for a name 
for a 3-D visualisation module, historically standing for New 
VIZualisation (as a replacement for SG3d). The original 3-D display 
module from the '80s was called d.3d and now that it has been removed it 
seems a good time to re-use the name. Although the original d.3d did use 
the Raster drawing library and the new one wouldn't, so Glynn's objection 
still applies here.


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