[GRASS-dev] Re: wxNviz toolbar

Mon Aug 22 02:38:15 EDT 2011

On Aug 21, 2011, at 10:10 PM, Helena Mitasova wrote:

> I tried it out and it is much better now, the switching between 2d,3d worked well even after zoom
> and the icons are much simpler now - 
> perhaps you can put the save nviz_cmd and 3D settings 3D help buttong after Hardcopy map utility
> to make it a little bit more organized by the type of functionality.
> 
> I had few small issues and one big one with z-exag.
> 
> I have a problem with z-exag set to one when it isn't actually one in real-world coordinates.
> Michael, I think that z-exag should reflect the actual z-exagerration,
> so that I know how much is my surface exagerrated when I am looking at it -
> for example the following images have z-exag one and both are obviously greatly
> exagerrated vertically - just by knowing the place it looks like z-exag
> 0.15 gives me a realistic topography but if you don't know the place
> there is no way to know. 
> http://skagit.meas.ncsu.edu/~helena/grasswork/zexag_1issue.tif
> this is the DEM from nc_spm_08 and we really don't have this kind of mountains here 
> (it is 10 times exagerated with z-exag=1)
> http://skagit.meas.ncsu.edu/~helena/grasswork/testwxnviz_z1elev.tif
> 
> There may be other options how to handle this:
> - keep z-exg as it used to be, reflecting the actual z-exageration based on the raster values
> (separate handling of latlong could be added to avoid extremely low z-exag
> due to different units - true z-exag could be used by computing the horizontal
> distance associated with the lat/long angles defining the region displayed)
> - have z-exag start as 1 (which is not very convenient for my example DEMs as you can see
> because I don't get much space on the slider to give a more realistic exageration )
> and provide somewhere the value of actual exageration
> - have z-exag start as 1 reflecting actual exageration 1 even if the surface will look completely flat
> (but this won't workif z-values range is magnitudes larger than x,y values range as for lat/long)
> 
> Hamish, how does the new setting work for you? 

IMHO, the place to fix this is in exag.c

That is where the default 3D height is set for any map, based on the horizontal and vertical ranges. The problem with latlon maps is that the vertical units are not the same as the horizontal units. My understanding is that because this is a common occurrence, there are C functions to deal with the rescaling. These should be applied in exag.c. Then latlon maps would look the same as projected maps. If the default height settings were being calculated in wxPython, we could do it in a python module. But they are calculated in this C module, so I think that this is the place to do it. 

An "exaggeration" value of 0.00005 (which made a normal-looking map previously) means to most people that the displayed height is much less than the real world view (i.e., 0.00005 X the true vertical perspective). 

I'd fix exag.c but don't know C or how to call the relevant rescaling functions. I'm hoping that one of you folks knows how to do this. 

> 
> Another issue that does not work very well is fine resolution setting.
> The original intent was for fine resolution set to 1 to be the resolution of the original raster
> (later on changed to region resolution which could be set to the rater resolution) 
> to avoid artifacts in the surface due to nn resampling
> http://skagit.meas.ncsu.edu/~helena/grasswork/secref_resampling.png
> When adjusting the 3D view to map display zoom the resolution can get easily higher that the original
> raster resolution, leading to resampling and then the surface looks like there is a problem 
> with the data (there used to be lots of artifacts like this in older DEMs).
> Perhaps a warning should be given to the user that his DEM is resampled and the displayed
> surface may have artifacts or the 3D view just should not display anything at resolution
> higher than what the DEM has.

Good points. I'm still not sure exactly what is happening here though. When you change the computational region to match the display, it changes the region extents but not the region resolution. On the other hand, the display works by keeping the number of pixels constant (for a given window size) regardless of the map zoom/extents. So very large maps are displayed with fewer pixels than cells and a close-up of a region is displayed with more pixels than cells. 

Is NVIZ registering the display resolution or the region resolution? 

I've attached a very close up of a section of elevation.dem from Spearfish with nviz resolution set to 1. To me it looks like it is displaying perfectly. This is indeed what the DEM looks like close up in 3D. But I guess it depends on what we expect to see. Should nviz be smoothing out the cells of the DEM at this scale? If so, then it should take the resolution from the region and not from the display. *Can* nviz create a smoothed landscape from such a small number of cells at this kind of scale? With respect to horizontal extent, it is very nice to have nviz finally display in 3D what I'm seeing in 2D. So I like it that wxNVIZ is using the display to define the horizontal extent of the 3D display. I'm not sure how best to deal with the resolution issue.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nviztest.jpg
Type: image/jpg
Size: 67898 bytes
Desc: nviztest.jpg
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20110821/1c8734d0/nviztest-0001.jpg
-------------- next part --------------

> 
> Just a small issue - 
> default size of point icon is 100 - it looks like it is in map units (100m) - I think it should be in pixels, perhaps 10?

These have always been in map units (even in TclTk IIRC). But having them in pixels would make them more consistent with the 2D display.

> 
> I got wxGUI crashed twice
> 
> - when I accidentally added a vector with 6.4 topology while 3D is open 

This happened to me too.

> -if I add it when 2D is open it suggests correctly to rebuild topology and does not crash
> - when I digitized area and right clicked to finish it (it might have been my problem).

This is a bug that I reported some time back. 

> 
> I did not have a chance to test the thematic mapping, but the options look great both for lines and points.

Good for colors, but sizing is broken. I emailed a report of this today.

> 
> Thanks a lot for all the great work,

Ditto for me.

Michael

> 
> Helena
> 

____________________
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 Aug 21, 2011, at 10:05 AM, Anna Kratochvílová wrote:
> 
>> Hi all,
>> 
>> 2011/8/21 Martin Landa <landa.martin at gmail.com>:
>>> Hi,
>>> 
>>> 2011/8/20 Anna Kratochvílová <kratochanna at gmail.com>:
>>>> I suggest to change the toolbar like this: remove tools for switching
>>>> pages, remove quit, the rest would be moved to layer manager (to
>>>> second row of toolbars) and the icons for settings and help could be
>>>> changed a little bit to differ from the GUI settings and help.
>>>> 
>> 
>> I changed the toolbar as I wrote here.  I changed also the code
>> responsible for switching between 2D/3D/digitizer so I would
>> appreciate if someone could test it more.
>> 
>> Anna
>> 
>>>> Please tell me if you agree.
>>> 
>>> generally speaking I agree with this proposal. Martin
>>> 
>>> --
>>> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
>>> 
> 