[GRASS-dev] wxNviz toolbar

GRASS GIS GRASS GIS developer
1

Hi,

I would like to ask you what do you think about the wxNviz toolbar and
its placement. Toolbar consists of two parts - one part controls
current page (like surface data) in Layer Manager's 3D view tab. The
other part consists of tool for generating nviz_cmd command, settings
and quit 3D view.

Toolbar is now located in Map Display window. The main advantage is
that there is plenty of space for it. Problem is that it is actually
not related to Map Display, it mainly controls Layer Manager window.
So one option is to move this toolbar to Layer Manager window although
I think it's not the best solution. As you can see from the attached
screenshot, there would be too many toolbars. And the tools for
switching pages are quite pointless here I think. So this leads me to
the question: are these tools useful and if so than where should they
be located? Another option could be splitting the toolbar in those two
parts I mentioned above and one part can be located in Map Display and
the other in Layer Manager.

I would be glad if you tell me what do you think about this problem,
if I should change the toolbar somehow.

Thanks
Anna

(attachments)

nviz_toolbar.jpg

2

Anna,

I agree about the duplication. We don't really need the page switch buttons.

The 3D mode view tools do not work AFAICT. They may be a placeholder for future plans. But if so, they should be deactivated until they are functional to avoid user confusion IMHO.

The generate NVIZ command could be useful, as is help.

I'm not sure that the quit button does anything different from switching back to 2D mode. If not, it too could be removed.

If the help on the layer manager could be made sensitive to context so that it went to 3D help when the 3D view page is active, we're down to one.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 19, 2011, at 7:26 AM, Anna Kratochvílová wrote:

Hi,

I would like to ask you what do you think about the wxNviz toolbar and
its placement. Toolbar consists of two parts - one part controls
current page (like surface data) in Layer Manager's 3D view tab. The
other part consists of tool for generating nviz_cmd command, settings
and quit 3D view.

Toolbar is now located in Map Display window. The main advantage is
that there is plenty of space for it. Problem is that it is actually
not related to Map Display, it mainly controls Layer Manager window.
So one option is to move this toolbar to Layer Manager window although
I think it's not the best solution. As you can see from the attached
screenshot, there would be too many toolbars. And the tools for
switching pages are quite pointless here I think. So this leads me to
the question: are these tools useful and if so than where should they
be located? Another option could be splitting the toolbar in those two
parts I mentioned above and one part can be located in Map Display and
the other in Layer Manager.

I would be glad if you tell me what do you think about this problem,
if I should change the toolbar somehow.

Thanks
Anna
<nviz_toolbar.jpg>

3

Hi all,

2011/8/19 Michael Barton <Michael.Barton@asu.edu>:

Anna,

I agree about the duplication. We don't really need the page switch buttons.

The 3D mode view tools do not work AFAICT. They may be a placeholder for future plans. But if so, they should be deactivated until they are functional to avoid user confusion IMHO.

If you mean the zoom tools they are disabled in 3D mode. By
deactivating you mean to hide them completely? If so, I wouldn't do
that, disabling is better (not so confusing) in my opinion.

The generate NVIZ command could be useful, as is help.

I'm not sure that the quit button does anything different from switching back to 2D mode. If not, it too could be removed.

It does the same and I'm not against removing it. It has only one
advantage - one mouse click instead of two when switching to 2D by
combobox.

If the help on the layer manager could be made sensitive to context so that it went to 3D help when the 3D view page is active, we're down to one.

I don't think it should be context sensitive. If user would like to
change GUI settings he would need to quit 3D view (if active) first
which doesn't make sense.

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.

Please tell me if you agree.

Thanks in advance

Anna

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 19, 2011, at 7:26 AM, Anna Kratochvílová wrote:

Hi,

I would like to ask you what do you think about the wxNviz toolbar and
its placement. Toolbar consists of two parts - one part controls
current page (like surface data) in Layer Manager's 3D view tab. The
other part consists of tool for generating nviz_cmd command, settings
and quit 3D view.

Toolbar is now located in Map Display window. The main advantage is
that there is plenty of space for it. Problem is that it is actually
not related to Map Display, it mainly controls Layer Manager window.
So one option is to move this toolbar to Layer Manager window although
I think it's not the best solution. As you can see from the attached
screenshot, there would be too many toolbars. And the tools for
switching pages are quite pointless here I think. So this leads me to
the question: are these tools useful and if so than where should they
be located? Another option could be splitting the toolbar in those two
parts I mentioned above and one part can be located in Map Display and
the other in Layer Manager.

I would be glad if you tell me what do you think about this problem,
if I should change the toolbar somehow.

Thanks
Anna
<nviz_toolbar.jpg>

4

Anna,

Some misunderstanding of my suggestions. I try to clarify below

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 Aug 20, 2011, at 8:20 AM, Anna Kratochvílová wrote:

Hi all,

2011/8/19 Michael Barton <Michael.Barton@asu.edu>:

Anna,

I agree about the duplication. We don't really need the page switch buttons.

The 3D mode view tools do not work AFAICT. They may be a placeholder for future plans. But if so, they should be deactivated until they are functional to avoid user confusion IMHO.

If you mean the zoom tools they are disabled in 3D mode. By
deactivating you mean to hide them completely? If so, I wouldn't do
that, disabling is better (not so confusing) in my opinion.

No. I do not mean the zoom tools. We are only referring to the buttons on the special nviz toolbar.

I mean the button with an icon that looks like a gear wheel or cog wheel. It opens up a set of notebook pages for nviz 'view tools'. It is possible to type in values for view parameters that are controlled by sliders and the display puck in the main interface. **BUT** these are not updated with the current values, and typing something in the text boxes has no effects on the view AFAICT. These have been around in one form or other for quite a while. I fixed an older version once so that they actually updated when the view changed, and changed the view when values were entered. But it looks like they do not do anything now. I suggest disabling these until they are working. Otherwise, a user will try to put in values and wonder why nothing happens.

The generate NVIZ command could be useful, as is help.

I'm not sure that the quit button does anything different from switching back to 2D mode. If not, it too could be removed.

It does the same and I'm not against removing it. It has only one
advantage - one mouse click instead of two when switching to 2D by
combobox.

Not much difference in motor actions.

If the help on the layer manager could be made sensitive to context so that it went to 3D help when the 3D view page is active, we're down to one.

I don't think it should be context sensitive. If user would like to
change GUI settings he would need to quit 3D view (if active) first
which doesn't make sense.

This is not what I'm talking about. There is a button with a 'life preserver ring' icon that activates wxNVIZ help. There is also an identical-looking help button on the main layer manager button bar that brings up general GRASS help. What I suggest is that when you are in the '3D view' page of the main notebook (tabs at the bottom of the layer manager), pressing the help button in the layer manager would bring up wxNVIZ help. When you are on the "Map layers" page, pressing this button would bring up general layer manger help (or GRASS help), etc.

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.

Please tell me if you agree.

Like the current wxNVIZ toolbar in the display window, it would be best if any special 3D display button bar only appear when the 3D display is active. That may not be possible. If not, they should be disabled when switching pages to the map layer, command console, or other non-3D view pages.

Michael

Thanks in advance

Anna

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 19, 2011, at 7:26 AM, Anna Kratochvílová wrote:

Hi,

I would like to ask you what do you think about the wxNviz toolbar and
its placement. Toolbar consists of two parts - one part controls
current page (like surface data) in Layer Manager's 3D view tab. The
other part consists of tool for generating nviz_cmd command, settings
and quit 3D view.

Toolbar is now located in Map Display window. The main advantage is
that there is plenty of space for it. Problem is that it is actually
not related to Map Display, it mainly controls Layer Manager window.
So one option is to move this toolbar to Layer Manager window although
I think it's not the best solution. As you can see from the attached
screenshot, there would be too many toolbars. And the tools for
switching pages are quite pointless here I think. So this leads me to
the question: are these tools useful and if so than where should they
be located? Another option could be splitting the toolbar in those two
parts I mentioned above and one part can be located in Map Display and
the other in Layer Manager.

I would be glad if you tell me what do you think about this problem,
if I should change the toolbar somehow.

Thanks
Anna
<nviz_toolbar.jpg>

5

Hi,

sorry for misunderstanding,

2011/8/20 Michael Barton <Michael.Barton@asu.edu>:

Anna,

Some misunderstanding of my suggestions. I try to clarify below

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 Aug 20, 2011, at 8:20 AM, Anna Kratochvílová wrote:

Hi all,

2011/8/19 Michael Barton <Michael.Barton@asu.edu>:

Anna,

I agree about the duplication. We don't really need the page switch buttons.

The 3D mode view tools do not work AFAICT. They may be a placeholder for future plans. But if so, they should be deactivated until they are functional to avoid user confusion IMHO.

If you mean the zoom tools they are disabled in 3D mode. By
deactivating you mean to hide them completely? If so, I wouldn't do
that, disabling is better (not so confusing) in my opinion.

No. I do not mean the zoom tools. We are only referring to the buttons on the special nviz toolbar.

I mean the button with an icon that looks like a gear wheel or cog wheel. It opens up a set of notebook pages for nviz 'view tools'. It is possible to type in values for view parameters that are controlled by sliders and the display puck in the main interface. **BUT** these are not updated with the current values, and typing something in the text boxes has no effects on the view AFAICT. These have been around in one form or other for quite a while. I fixed an older version once so that they actually updated when the view changed, and changed the view when values were entered. But it looks like they do not do anything now. I suggest disabling these until they are working. Otherwise, a user will try to put in values and wonder why nothing happens.

I didn't catch you mean the settings dialog. It's true this dialog
must be fixed, I'll do that. The main purpose of this dialog is not to
set values to change the current view or other features (this can be
done in 3D view tab). It should manage default values - these values
are (or at least should be) used when first switching to 3D view. On
Apply button the current values in dialog should be used to change
current state in nviz (this doesn't work now). Save button behaves
like Apply and in addition the values are written to settings file
(this works AFAIK). Values in this dialog shouldn't be updated when
view or other features change. These default values are not used when
switching to 3D view for the second time, I suppose it's better to
display the state in the moment when user switched to 2D view.

The generate NVIZ command could be useful, as is help.

I'm not sure that the quit button does anything different from switching back to 2D mode. If not, it too could be removed.

It does the same and I'm not against removing it. It has only one
advantage - one mouse click instead of two when switching to 2D by
combobox.

Not much difference in motor actions.

If the help on the layer manager could be made sensitive to context so that it went to 3D help when the 3D view page is active, we're down to one.

I don't think it should be context sensitive. If user would like to
change GUI settings he would need to quit 3D view (if active) first
which doesn't make sense.

This is not what I'm talking about. There is a button with a 'life preserver ring' icon that activates wxNVIZ help. There is also an identical-looking help button on the main layer manager button bar that brings up general GRASS help. What I suggest is that when you are in the '3D view' page of the main notebook (tabs at the bottom of the layer manager), pressing the help button in the layer manager would bring up wxNVIZ help. When you are on the "Map layers" page, pressing this button would bring up general layer manger help (or GRASS help), etc.

This behaviour would be confusing, switching tabs shouldn't change
behaviour of the same button. I still suggest to have a different (but
similar) icon.

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.

Please tell me if you agree.

Like the current wxNVIZ toolbar in the display window, it would be best if any special 3D display button bar only appear when the 3D display is active. That may not be possible. If not, they should be disabled when switching pages to the map layer, command console, or other non-3D view pages.

So far I don't see any reason why it wouldn't be possible. I'll try it
of course.

Anna

Michael

Thanks in advance

Anna

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 19, 2011, at 7:26 AM, Anna Kratochvílová wrote:

Hi,

I would like to ask you what do you think about the wxNviz toolbar and
its placement. Toolbar consists of two parts - one part controls
current page (like surface data) in Layer Manager's 3D view tab. The
other part consists of tool for generating nviz_cmd command, settings
and quit 3D view.

Toolbar is now located in Map Display window. The main advantage is
that there is plenty of space for it. Problem is that it is actually
not related to Map Display, it mainly controls Layer Manager window.
So one option is to move this toolbar to Layer Manager window although
I think it's not the best solution. As you can see from the attached
screenshot, there would be too many toolbars. And the tools for
switching pages are quite pointless here I think. So this leads me to
the question: are these tools useful and if so than where should they
be located? Another option could be splitting the toolbar in those two
parts I mentioned above and one part can be located in Map Display and
the other in Layer Manager.

I would be glad if you tell me what do you think about this problem,
if I should change the toolbar somehow.

Thanks
Anna
<nviz_toolbar.jpg>

6

W dniu 20.08.2011 22:11, Anna Kratochvílová pisze:

2011/8/20 Michael Barton<Michael.Barton@asu.edu>:

If the help on the layer manager could be made sensitive to
context so that it went to 3D help when the 3D view page is
active, we're down to one.

I don't think it should be context sensitive. If user would like
to change GUI settings he would need to quit 3D view (if active)
first which doesn't make sense.

This is not what I'm talking about. There is a button with a 'life
preserver ring' icon that activates wxNVIZ help. There is also an
identical-looking help button on the main layer manager button bar
that brings up general GRASS help. What I suggest is that when you
are in the '3D view' page of the main notebook (tabs at the bottom
of the layer manager), pressing the help button in the layer
manager would bring up wxNVIZ help. When you are on the "Map
layers" page, pressing this button would bring up general layer
manger help (or GRASS help), etc.

This behaviour would be confusing, switching tabs shouldn't change
behaviour of the same button. I still suggest to have a different
(but similar) icon.

Sort of this?
http://trac.osgeo.org/osgeo/changeset/6982/graphics

regards,
Robert

7

2011/8/20 Robert Szczepanek <robert@szczepanek.pl>:

W dniu 20.08.2011 22:11, Anna Kratochvílová pisze:

2011/8/20 Michael Barton<Michael.Barton@asu.edu>:

If the help on the layer manager could be made sensitive to
context so that it went to 3D help when the 3D view page is
active, we're down to one.

I don't think it should be context sensitive. If user would like
to change GUI settings he would need to quit 3D view (if active)
first which doesn't make sense.

This is not what I'm talking about. There is a button with a 'life
preserver ring' icon that activates wxNVIZ help. There is also an
identical-looking help button on the main layer manager button bar
that brings up general GRASS help. What I suggest is that when you
are in the '3D view' page of the main notebook (tabs at the bottom
of the layer manager), pressing the help button in the layer
manager would bring up wxNVIZ help. When you are on the "Map
layers" page, pressing this button would bring up general layer
manger help (or GRASS help), etc.

This behaviour would be confusing, switching tabs shouldn't change
behaviour of the same button. I still suggest to have a different
(but similar) icon.

Sort of this?
http://trac.osgeo.org/osgeo/changeset/6982/graphics

Hi Robert,

this is exactly what I mean! Thanks very much, I wanted to ask you for
it. Please, could you do the same with the settings icon (cogwheel)?

Anna

regards,
Robert

8

W dniu 20.08.2011 23:13, Anna Kratochvílová pisze:

Hi Robert,

this is exactly what I mean! Thanks very much, I wanted to ask you for
it. Please, could you do the same with the settings icon (cogwheel)?

Anna

Here it is:
http://trac.osgeo.org/osgeo/changeset/6983/graphics
Thank you for this great work with wxNviz!

Robert

9

Hi,

2011/8/20 Anna Kratochvílová <kratochanna@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.

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

10

Hi all,

2011/8/21 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/8/20 Anna Kratochvílová <kratochanna@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

11

It looks very nice. Thanks.

For the 3D view settings, it would be nice to have a button 'set to current' to go along with 'set to default'. That way, current view settings could be saved as for future sessions. Once a view setting has been saved, is there any way to get back to the original defaults that ship with GRASS? Does 'set to default' do that? Or does it set the view to whatever was saved?

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 Aug 21, 2011, at 7:05 AM, Anna Kratochvílová wrote:

Hi all,

2011/8/21 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/8/20 Anna Kratochvílová <kratochanna@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> * Studijní program Geodézie a kartografie – GeoWikiCZ

12

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?

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.

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?

I got wxGUI crashed twice

- when I accidentally added a vector with 6.4 topology while 3D is open
-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).

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

Thanks a lot for all the great work,

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu

On Aug 21, 2011, at 10:05 AM, Anna Kratochvílová wrote:

Hi all,

2011/8/21 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/8/20 Anna Kratochvílová <kratochanna@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

13

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.

(attachments)

nviztest.jpg
ATT00001…txt (2.21 KB)

14

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.

not really - when visualized in nviz the grid is converted to TIN and with gouraud shading you should not see squares.
(without the smooth shading you would see sloped triangles, not flat squares)
When you see squares, your DEM is resampled by nearest neighbor - I have it explained in detail in this lecture
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ldata.ppt
see slides 29 and 31, slide 33 explains why you don't always see flat squares (it depends on the relation between the original
and new resolution).

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.

that is one of the solutions - if taken from region settings, then the user should be in control of the resampling
(of course if he/she actually knows that GRASS does automatic resampling to region resolution).

*Can* nviz create a smoothed landscape from such a small number of cells at this kind of scale?

as shouwn above, it is not the matter of having small number of cells - you get the squares even for the larger DEMs
if resampling is going on and if the resolution of your screen displays every pixel. And if you do not resample,
with gouraud shading your surface will be smooth even for a small number of cells, it just looks rather fuzzy then.
(you can try this in old nviz which has the resolution controled by g.region, just make sure your region is set to the
DEM that you are displaying.).

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.

yes, I like that too.

I'm not sure how best to deal with the resolution issue.

avoiding the nn resampling should fix it, although I am not sure how difficult that would be.
Another option would be to do bilinear interpolation when resampling FP continuous field maps
(but we can have FP maps that are not continuous fields where interpolation is not appropriate).

Helena

<nviztest.jpg><ATT00001..txt>

15

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.

not really - when visualized in nviz the grid is converted to TIN and with gouraud shading you should not see squares.
(without the smooth shading you would see sloped triangles, not flat squares)
When you see squares, your DEM is resampled by nearest neighbor - I have it explained in detail in this lecture
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ldata.ppt
see slides 29 and 31, slide 33 explains why you don't always see flat squares (it depends on the relation between the original
and new resolution).

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.

that is one of the solutions - if taken from region settings, then the user should be in control of the resampling
(of course if he/she actually knows that GRASS does automatic resampling to region resolution).

*Can* nviz create a smoothed landscape from such a small number of cells at this kind of scale?

as shouwn above, it is not the matter of having small number of cells - you get the squares even for the larger DEMs
if resampling is going on and if the resolution of your screen displays every pixel. And if you do not resample,
with gouraud shading your surface will be smooth even for a small number of cells, it just looks rather fuzzy then.
(you can try this in old nviz which has the resolution controled by g.region, just make sure your region is set to the
DEM that you are displaying.).

OK

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.

yes, I like that too.

I'm not sure how best to deal with the resolution issue.

avoiding the nn resampling should fix it, although I am not sure how difficult that would be.
Another option would be to do bilinear interpolation when resampling FP continuous field maps
(but we can have FP maps that are not continuous fields where interpolation is not appropriate).

It seems like the easiest would be to take the horizontal extents from the display region but use the map's native resolution for the resolution. Resampling every time NVIZ starts could slow it down a lot.

But I guess I'd better grab some screenshots of a DEM the way it works now since that is a great display for class.

Michael

Helena

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 22, 2011, at 6:53 AM, Helena Mitasova wrote:

16

Hi all,

On Mon, Aug 22, 2011 at 7:04 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

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.

not really - when visualized in nviz the grid is converted to TIN and with gouraud shading you should not see squares.
(without the smooth shading you would see sloped triangles, not flat squares)
When you see squares, your DEM is resampled by nearest neighbor - I have it explained in detail in this lecture
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ldata.ppt
see slides 29 and 31, slide 33 explains why you don't always see flat squares (it depends on the relation between the original
and new resolution).

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.

that is one of the solutions - if taken from region settings, then the user should be in control of the resampling
(of course if he/she actually knows that GRASS does automatic resampling to region resolution).

*Can* nviz create a smoothed landscape from such a small number of cells at this kind of scale?

as shouwn above, it is not the matter of having small number of cells - you get the squares even for the larger DEMs
if resampling is going on and if the resolution of your screen displays every pixel. And if you do not resample,
with gouraud shading your surface will be smooth even for a small number of cells, it just looks rather fuzzy then.
(you can try this in old nviz which has the resolution controled by g.region, just make sure your region is set to the
DEM that you are displaying.).

OK

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.

yes, I like that too.

I'm not sure how best to deal with the resolution issue.

avoiding the nn resampling should fix it, although I am not sure how difficult that would be.
Another option would be to do bilinear interpolation when resampling FP continuous field maps
(but we can have FP maps that are not continuous fields where interpolation is not appropriate).

It seems like the easiest would be to take the horizontal extents from the display region but use the map's native resolution for the resolution. Resampling every time NVIZ starts could slow it down a lot.

I've just tried to fix this problem. Although I thought the resolution
was from computational region:

os.environ['GRASS_REGION'] = self.Map.SetRegion(windres = True)

it was recalculated to display resolution in

G_adjust_Cell_head(cellhd, TEST(F_ROWS), TEST(F_COLS));
line 158

because of rows and columns.
I changed the SetRegion method. I hope it won't affect some other
functionality.

Now fine resolution set to 1 should correspond to resolution of
computational region. Another possibility is to set original surface
resolution but I'm afraid there could be problems when surfaces have
different resolution.

BTW, Michael, this could help with #1427, please try it.

Anna

But I guess I'd better grab some screenshots of a DEM the way it works now since that is a great display for class.

Michael

Helena

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 22, 2011, at 6:53 AM, Helena Mitasova wrote:

17

What Helena and I were getting at was that in order for NVIZ to display a correctly smoothed surface, a resolution of 1 should correspond with the resolution of the original map (i.e., as returned by r.info -r), not the computational region. It is good that the horizontal extents of the 3D surface correspond to the display extents, which you should be able to obtain from os.environ['GRASS_REGION'] = self.Map.SetRegion(windres = True)

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 22, 2011, at 12:24 PM, Anna Kratochvílová wrote:

Hi all,

On Mon, Aug 22, 2011 at 7:04 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

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.

not really - when visualized in nviz the grid is converted to TIN and with gouraud shading you should not see squares.
(without the smooth shading you would see sloped triangles, not flat squares)
When you see squares, your DEM is resampled by nearest neighbor - I have it explained in detail in this lecture
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ldata.ppt
see slides 29 and 31, slide 33 explains why you don't always see flat squares (it depends on the relation between the original
and new resolution).

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.

that is one of the solutions - if taken from region settings, then the user should be in control of the resampling
(of course if he/she actually knows that GRASS does automatic resampling to region resolution).

*Can* nviz create a smoothed landscape from such a small number of cells at this kind of scale?

as shouwn above, it is not the matter of having small number of cells - you get the squares even for the larger DEMs
if resampling is going on and if the resolution of your screen displays every pixel. And if you do not resample,
with gouraud shading your surface will be smooth even for a small number of cells, it just looks rather fuzzy then.
(you can try this in old nviz which has the resolution controled by g.region, just make sure your region is set to the
DEM that you are displaying.).

OK

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.

yes, I like that too.

I'm not sure how best to deal with the resolution issue.

avoiding the nn resampling should fix it, although I am not sure how difficult that would be.
Another option would be to do bilinear interpolation when resampling FP continuous field maps
(but we can have FP maps that are not continuous fields where interpolation is not appropriate).

It seems like the easiest would be to take the horizontal extents from the display region but use the map's native resolution for the resolution. Resampling every time NVIZ starts could slow it down a lot.

I've just tried to fix this problem. Although I thought the resolution
was from computational region:

os.environ['GRASS_REGION'] = self.Map.SetRegion(windres = True)

it was recalculated to display resolution in

G_adjust_Cell_head(cellhd, TEST(F_ROWS), TEST(F_COLS));
line 158

because of rows and columns.
I changed the SetRegion method. I hope it won't affect some other
functionality.

Now fine resolution set to 1 should correspond to resolution of
computational region. Another possibility is to set original surface
resolution but I'm afraid there could be problems when surfaces have
different resolution.

BTW, Michael, this could help with #1427, please try it.

Anna

But I guess I'd better grab some screenshots of a DEM the way it works now since that is a great display for class.

Michael

Helena

______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

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

On Aug 22, 2011, at 6:53 AM, Helena Mitasova wrote: