On Dec 18, 2008, at 4:21 AM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org > wrote:
Date: Thu, 18 Dec 2008 12:21:17 +0100
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] 6.4rc1
To: Hamish <hamish_b@yahoo.com>
Cc: grass-dev <grass-dev@lists.osgeo.org>
Message-ID:
<f8fe65c40812180321x5f978efqda73bb9c9a67ea0f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
2008/12/1 Martin Landa <landa.martin@gmail.com>:
2008/12/1 Hamish <hamish_b@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
On Thu, 18 Dec 2008, Michael Barton wrote:
On Dec 18, 2008, at 4:21 AM, <grass-dev-request@lists.osgeo.org> <grass-dev-request@lists.osgeo.org> wrote:
Date: Thu, 18 Dec 2008 12:21:17 +0100
From: "Martin Landa" <landa.martin@gmail.com>
Subject: Re: [GRASS-dev] 6.4rc1
To: Hamish <hamish_b@yahoo.com>
Cc: grass-dev <grass-dev@lists.osgeo.org>
Message-ID:
<f8fe65c40812180321x5f978efqda73bb9c9a67ea0f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
2008/12/1 Martin Landa <landa.martin@gmail.com>:
2008/12/1 Hamish <hamish_b@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