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 <[email protected]> >> 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 > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
