[GRASS-dev] Re: z-exag in wxnviz

[Michael Barton]

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 at 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
>