[GRASS-dev] z-exag in wxnviz

[Michael Barton]

While I understand the problems, if we revert it, it will be much worse. The initial z-exag will be set to 1000 for latlon and even a value of 1 will be enormously too big. This is why I tried to improve it.

The previous way it was working was even more arbitrary than it is now. It is making no conversion whatsoever between degrees and meters. It is simply using a ratio between the maximum vertical range and the maximum horizontal range. So the conversion factor is much different for areas of high mountains than for areas of low hills. And then the conversion factor was arbitrarily rescaled by a factor of 1, 100, or 1000--only one of those 3 values--to reset the decimal point.

Moreover, what does a vertical exaggeration of 0.0001 mean? To most people, I think that means that the vertical exaggeration is much much less than the "real" value, not a 1:1 vertical:horizontal ratio. 

We need to fix this properly. Reverting it will only make it even less useful than it is now.

Once I make a bit of time in the next couple weeks, I can dig back through it to find the places in the code where this is set (one is exag.c). Then maybe you all can take a look at it to see how best to improve it so that it works right. Does that sound OK?

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 26, 2011, at 12:49 PM, Anna Kratochvílová wrote:

> 2011/11/26 Hamish <hamish_b at yahoo.com>:
>> 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
>> 
> 
> Hi,
> 
> I think we should revert the changes in zexag, it's the only way to
> set real exaggeration. Very small zexag values with lat/lon maps are
> inconvenient but still it works. I like the possible solution with
> 1852*60*cos(lat) but I'm not sure I'll be able to implement it, I
> remember I tried to do something similar but I couldn't get it work
> (OGSF is quite messy). I can try again (but not now, maybe in the next
> few weeks).
> 
> Anna