[GRASS-dev] 6.4.2rc3 this week, then 6.4.2 by the holidays?

GRASS GIS GRASS GIS developer
1

Helena,

wxNVIZ in 6.4.2 is at the place where it was more or less a year and a half ago. It is sort of functional, but many things do not work. Anyone wanting to have a satisfying 3D imaging experience should use the TclTk version of NVIZ. I believe that wxNVIZ does not compile by default and IMHO, precompiled binaries probably should not compile it for wide distribution so that people don't get the wrong idea about its capabilities--which are extraordinarily good in GRASS 7. I'll probably stop compiling it soon.

I'm not sure about the wxdigitizer, but I *think* that it works pretty well. I wish I could compile the digitizer without wxNVIZ in 6.4.2. Anyone know how to do that?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2011, at 1:28 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Mon, 21 Nov 2011 20:02:17 -0500
From: Helena Mitasova <hmitaso@ncsu.edu>
Subject: Re: [GRASS-dev] 6.4.2rc3 this week, then 6.4.2 by the
       holidays?
To: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <D89E95C6-E783-4EAB-BDD3-229AC6B51963@ncsu.edu>
Content-Type: text/plain; charset=us-ascii

I think that this is a good plan - the latest changes definitely need testing.

Unrelated to init.sh I just compiled the release branch and I have the 3D view enabled in Map display,
however, when I run it, lighting does not work (and maybe other things as well)
- although this has been fixed in GRASS7.

Is this the intention? If yes, should there
be some message that to get the full functionality the user should run TclTk nviz
or would it be possible to backport the rest of wxnviz to GRASS6.4.2 release?
Or is the problem on my side that I did not update and compile wxnviz properly?

Helena

2

On Nov 21, 2011, at 8:56 PM, Michael Barton wrote:

Helena,

wxNVIZ in 6.4.2 is at the place where it was more or less a year and a half ago. It is sort of functional, but many things do not work. Anyone wanting to have a satisfying 3D imaging experience should use the TclTk version of NVIZ. I believe that wxNVIZ does not compile by default and IMHO, precompiled binaries probably should not compile it for wide distribution so that people don't get the wrong idea about its capabilities--which are extraordinarily good in GRASS 7. I'll probably stop compiling it soon.

I totally agree with that, Helena

I'm not sure about the wxdigitizer, but I *think* that it works pretty well. I wish I could compile the digitizer without wxNVIZ in 6.4.2. Anyone know how to do that?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2011, at 1:28 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Mon, 21 Nov 2011 20:02:17 -0500
From: Helena Mitasova <hmitaso@ncsu.edu>
Subject: Re: [GRASS-dev] 6.4.2rc3 this week, then 6.4.2 by the
      holidays?
To: GRASS developers list <grass-dev@lists.osgeo.org>
Message-ID: <D89E95C6-E783-4EAB-BDD3-229AC6B51963@ncsu.edu>
Content-Type: text/plain; charset=us-ascii

I think that this is a good plan - the latest changes definitely need testing.

Unrelated to init.sh I just compiled the release branch and I have the 3D view enabled in Map display,
however, when I run it, lighting does not work (and maybe other things as well)
- although this has been fixed in GRASS7.

Is this the intention? If yes, should there
be some message that to get the full functionality the user should run TclTk nviz
or would it be possible to backport the rest of wxnviz to GRASS6.4.2 release?
Or is the problem on my side that I did not update and compile wxnviz properly?

Helena

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

3

On Tue, Nov 22, 2011 at 3:09 AM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

On Nov 21, 2011, at 8:56 PM, Michael Barton wrote:

Helena,

wxNVIZ in 6.4.2 is at the place where it was more or less a year and a half ago. It is sort of functional, but many things do not work. Anyone wanting to have a satisfying 3D imaging experience should use the TclTk version of NVIZ.

...

Or backport at least wxNVIZ from GRASS 6.5 and still disable it from the
default compilation?

Markus

4

Hi,

2011/11/22 Markus Neteler <neteler@osgeo.org>:

[...]

Or backport at least wxNVIZ from GRASS 6.5 and still disable it from the
default compilation?

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

5

Markus Neteler:

Or backport at least wxNVIZ from GRASS 6.5 and still
disable it from the default compilation?

is it buggy, or just lacking the latest and greatest features?

if it is just lacking features it is easy enough to put a msg
"coming soon! if you want the full capability go file>nviz tcltk"
on the wxgui 3d control tab. if all you want is a quick look
at the 3d surface the only real control you need to work properly
is the positioning puck..

if it is buggy, then best to grey it out and ship 6.4.2 without
delay, and work on it soon after.

I was hoping that 6.4.2 could be the point where we really
really go bug-fixes-only for the 6.4 line, but as long as
backporting wxnviz bits does not touch code outside of
gui/wxpython/ I don't mind it being allowed to go from 40% to
80% for 6.4.3. I would not be very happy with deep changes to
lib/ogsf however.

2c,
Hamish

ps- what's the status of the wxVdigit sync?

6

Sounds like a good plan.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 22, 2011, at 2:42 AM, Martin Landa wrote:

Hi,

2011/11/22 Markus Neteler <neteler@osgeo.org>:

[...]

Or backport at least wxNVIZ from GRASS 6.5 and still disable it from the
default compilation?

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

7

Hi,

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

wxNviz is now in 6.5, testing welcomed

Anna

8

As much as I really like wxNviz, isn't 6.4.2 supposed to be frozen for new features so that it can be released soon?

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Nov 25, 2011, at 8:22 AM, "Anna Kratochvílová" <kratochanna@gmail.com> wrote:

Hi,

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

wxNviz is now in 6.5, testing welcomed

Anna

9

2011/11/25 Michael Barton <Michael.Barton@asu.edu>:

As much as I really like wxNviz, isn't 6.4.2 supposed to be frozen
for new features so that it can be released soon?

Sure. Martin spoke about 6.4.3:

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

... which means that it can happen *after* the 6.4.2 release.

Markus

10

Ok. Thanks for clarifying.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Nov 25, 2011, at 10:37 AM, "Markus Neteler" <neteler@osgeo.org> wrote:

2011/11/25 Michael Barton <Michael.Barton@asu.edu>:

As much as I really like wxNviz, isn't 6.4.2 supposed to be frozen
for new features so that it can be released soon?

Sure. Martin spoke about 6.4.3:

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

... which means that it can happen *after* the 6.4.2 release.

Markus

11

Hi,

Dne 25. listopadu 2011 16:58 Michael Barton <Michael.Barton@asu.edu> napsal(a):

As much as I really like wxNviz, isn't 6.4.2 supposed to be frozen for new features so that it can be released soon?

yes, frozen. I would personally expect 6.4.3 in May or so...

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

12

Hi,

2011/11/25 Markus Neteler <neteler@osgeo.org>:

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

... which means that it can happen *after* the 6.4.2 release.

right, Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

13

Ahoj,

Dne 25. listopadu 2011 16:22 Anna Kratochvílová
<kratochanna@gmail.com> napsal(a):

wxNviz is now in 6.5, testing welcomed

thanks Anna, great job!

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

14

2011/11/22 Martin Landa <landa.martin@gmail.com>:

[...]

for testing. So at this point I will disable wxNviz in `relbr64`.

done in r49360. Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

15

Thanks Martin.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 25, 2011, at 1:23 PM, Martin Landa wrote:

2011/11/22 Martin Landa <landa.martin@gmail.com>:

[...]

for testing. So at this point I will disable wxNviz in `relbr64`.

done in r49360. Martin

--
Martin Landa <landa.martin gmail.com> * Studijní program Geodézie a kartografie – GeoWikiCZ

16

Anna,

thank you for backporting wxnviz, I just compiled it and it runs great, even with some highly specialized data
(e.g. terrestrial lidar scans at 0.01m resolution).
There are few things that still have issues (mostly features that never really worked in nviz and may be only Mac related)

Appearance:
- scale bar does not work with my terrestrial lidar x,y data (but it worked in grass7 with different data)
- add legend > OK: nothing gets drawn in 3D but the legend shows up when I switch to 2D
but when I clicked delete scalebar (which was not drawn),
my surface disapeared but the legend showed up along with white and black background
(which I assume was supposed to be transparent, because when I moved the legend the surface
was under it - we already discussed this, it may be my problem, because it works for Michael).

General
- when I go from 3D view to 2D and then back to 3D I lose most of my settings
(viewing position, zexag, fringe size etc. - this would be OK if I could get a warning and question
whether I want to save my 3D viewing state before switching)
- similarly, when I add volume to Map layers I lose my view settings and the 3D view goes back to default

Volumes:
- change of region by g.region seems to be ignored (or I missed something), I had to restart GRASS with the new region
to get the 3D region for volumes right. Given that the default top, botom is 1,0, if GRASS
starts with the default 3D region settings volumes do not work because there is just one level.
- isosurfaces work with my terrestrial lidar data but the slices don't, it seems that it is due
my resolution being 0.3m, when I change it to 1m I get at least some limited slicing
  - this may be in ogsf becuase slices in nviz do not work with this data either
- changing color to constant did not change the color of the isosurface
- when working with volumes the following error message shows up :

Traceback (most recent call last):
  File "/Users/helena/grassdev6/develbranch_6/dist.i386
-apple-darwin10.8.0/etc/wxpython/gui_modules/nviz_tools.py",
line 2829, in OnSetRaster3D

self.UpdateVolumePage(layer, data, updateName = False)
  File "/Users/helena/grassdev6/develbranch_6/dist.i386
-apple-darwin10.8.0/etc/wxpython/gui_modules/nviz_tools.py",
line 4762, in UpdateVolumePage

box.SetChecked(range(len(isosurfaces)))
AttributeError
:
'CheckListBox' object has no attribute 'SetChecked'
Traceback (most recent call last):
  File "/Users/helena/grassdev6/develbranch_6/dist.i386
-apple-darwin10.8.0/etc/wxpython/gui_modules/nviz_tools.py",
line 3667, in OnVolumeMode

self.UpdateVolumePage(layer, data, updateName = False)
  File "/Users/helena/grassdev6/develbranch_6/dist.i386
-apple-darwin10.8.0/etc/wxpython/gui_modules/nviz_tools.py",
line 4774, in UpdateVolumePage

box.SetChecked(range(len(slices)))
AttributeError
:
'CheckListBox' object has no attribute 'SetChecked'

Thank you,

Helena

On Nov 25, 2011, at 10:22 AM, Anna Kratochvílová wrote:

Hi,

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

wxNviz is now in 6.5, testing welcomed

Anna

17

I would like to ask users of nviz to try out wxnviz and provide some feedback on the current settings of z-exag.
We discussed it quite a bit before it was changed, but as I am using it now, I find the new setting in wxnviz confusing.
Here is the issue (Anna, Michael, please correct me if I am wrong):

- in nviz the z-exag is set to 1 when x:y:z=1:1:1 (e.g. assuming that x,y,z are all in same units this works well for elevation surfaces).
To highlight the topography in flat landscapes, nviz often starts with zexag set to a number higher than 1,
but you can always get to the realistic vertical view by setting zexag to 1. The problem with this approach is that when you
have latlong or some other type of data with raster values much larger than the values of horizontal coordinates
the zexag can be very small (.eg. 0.00001) which is not very convenient.

- in wxnviz to avoid the very small zexag for latlong, zexag is set to 1 for z-exageration that looks good (I did not check
how the "good" is computed) which makes for a good start for most data. Problem is that now it is not possible
to tell what the actual vertical scaling is. For example, for most of my data (including nc_spm_08) I now have
to drag z-exag to anywhere between 0.2-0.4 to get realistic looking surface and I am not sure whether I am making
the surface flatter than it is in reality or when I am getting it right (the real x:y:z=1:1:1).
If the new behavior is preferable, should we at least have some indicator (perhaps along the slider) of what the true vertical scale is?
Or should we go back to nviz setting or even more back to SG3d setting where if I remember correctly
it started with x:y:z=1:1:1?

Helena

On Nov 25, 2011, at 10:22 AM, Anna Kratochvílová wrote:

Hi,

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

wxNviz is now in 6.5, testing welcomed

Anna

18

Hi Helena,

Perhaps the SG3D version is looking at, but the previous scaling in wxNVIZ did not correspond to the 'real' scale. I dug into the code quite deeply. What appears to have been happening was that a ratio of the x range, y range, and z range was calculated in the native units for those dimensions (e.g., for latlon, x and y are calculated in degrees and z is calculated in meters). Then, based on that ratio, a scaling factor is set to either 1:1, 1:100, or 1:1000. It is not clear to me exactly how this is calculated as it spans multiple classes and methods in the C and wxPython modules. The scaling factor is then used to instantiate the z-exag slider and an initial z value. The z values were way, way too high for latlon regions. Anna made it possible to type in a smaller value, which made it appear better. But I don't think that smaller value was related in any direct way to the actual scaling. What I did was to take the initial optimal scaling factor (and I'm not sure how it is calculated) and instantiate a z-exag slider that varies from this initial optimum (=1) to 100.

What needs to be done IMHO is to figure out what a 1:1 horizontal/vertical ratio should be for any map and set that to 1 in the z-exag slider. BUT, we need to decide what a 1:1 ratio really is. This is easy for a projected DEM. Using grass libraries, it should be pretty easy for a latlon DEM too. For other kinds of maps (e.g., horizontal in meters and vertical in K-factor values) we need to decide how to treat these. This calculation should be made where the scaling is now done. I agree with you that it needs to be improved, but the way it was before I "fixed" it was worse than it is now.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Nov 25, 2011, at 9:58 PM, Helena Mitasova wrote:

I would like to ask users of nviz to try out wxnviz and provide some feedback on the current settings of z-exag.
We discussed it quite a bit before it was changed, but as I am using it now, I find the new setting in wxnviz confusing.
Here is the issue (Anna, Michael, please correct me if I am wrong):

- in nviz the z-exag is set to 1 when x:y:z=1:1:1 (e.g. assuming that x,y,z are all in same units this works well for elevation surfaces).
To highlight the topography in flat landscapes, nviz often starts with zexag set to a number higher than 1,
but you can always get to the realistic vertical view by setting zexag to 1. The problem with this approach is that when you
have latlong or some other type of data with raster values much larger than the values of horizontal coordinates
the zexag can be very small (.eg. 0.00001) which is not very convenient.

- in wxnviz to avoid the very small zexag for latlong, zexag is set to 1 for z-exageration that looks good (I did not check
how the "good" is computed) which makes for a good start for most data. Problem is that now it is not possible
to tell what the actual vertical scaling is. For example, for most of my data (including nc_spm_08) I now have
to drag z-exag to anywhere between 0.2-0.4 to get realistic looking surface and I am not sure whether I am making
the surface flatter than it is in reality or when I am getting it right (the real x:y:z=1:1:1).
If the new behavior is preferable, should we at least have some indicator (perhaps along the slider) of what the true vertical scale is?
Or should we go back to nviz setting or even more back to SG3d setting where if I remember correctly
it started with x:y:z=1:1:1?

Helena

On Nov 25, 2011, at 10:22 AM, Anna Kratochvílová wrote:

Hi,

On Tue, Nov 22, 2011 at 10:42 AM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

the latest wxNviz is available only in trunk. Together with Anna we
are planning in these days backport to devbr6 and immediately after
releasing 6.4.2 to backport wxNviz to `relbr64` to have enough time
for testing. So at this point I will disable wxNviz in `relbr64`.

Martin

wxNviz is now in 6.5, testing welcomed

Anna

19

Michael wrote:

What needs to be done IMHO is to figure out what a 1:1
horizontal/vertical ratio should be for any map and set that
to 1 in the z-exag slider. BUT, we need to decide what a 1:1
ratio really is. This is easy for a projected DEM. Using
grass libraries, it should be pretty easy for a latlon DEM
too.

exactly 1852m in a nautical mile.
exactly 60 nautical miles in a degree latitude.

that gives a basic meter to degree conversion for the map, BUT
it is not guaranteed that the DEM data is in meters, not feet
or anything else. r.support/r.info units= was added to record
this, but it is a freeform field so you can make it micro-Einsteins
per m^2 per sec, \mu and all, or whatever, so can only be used
as a hint if it is there and matches a known list.

tcltk nviz has a hack to support that, but it isn't fully
implemented, e.g. the lighting is still quite wacky for that.

theoretically for regions smaller than say 3 degrees in EW extent
lat/lon we might look at skewing the aspect ratio for cells by
1:cos(lat_center) to reduce the distortion. very crude but fast
and passable as a first order correction for something which
is for visible purposes only. or just display an error message
saying you should try to use a projected location instead.

Hamish

20

Helena wrote:

- in wxnviz to avoid the very small zexag for latlong,

another idea for lat/lon z-exag: just figure out what is 20-25% of the canvas height (or ~15% of the north-south image width),
and work backwards from there, rounding to the nearest nice
round number.

I don't know if there is any real way to escape from x:y:z ratios
of 1 : 1 : 1/(1852*60), as anything other than that is numerically
synthetic. if taking up the 1:cos(lat) aspect ratio adjustment
perhaps rather than converting the elevation data to degrees,
we could convert the ew, ns to "meters" to get ratios of
1852*60*cos(lat): 1852*60 : 1 as the cheap and dirty projection.
for global lat/lon views you probably wouldn't want to do that
though.

Hamish