[GRASS-dev] wxNviz issue: no visual output
Hi, while teaching at the Geostat2015 I had some suprising issue: in general no problem with wxNVIZ but in the following situation there is no output (also for the course participants, various OS): NC location # set computational region to map (using map metadata) g.region raster=elev_lid792_1m -p # flow accumulation with MFD r.watershed elevation=elev_lid792_1m accumulation=flowacc r.info -r flowacc min=0 max=91047 - show map in wxGUI: ok - 3D view: white No error message. I tried to adjust the view parameters but no way... Does anyone have an idea? g.version -rg version=7.0.2svn date=2015 revision=65960 build_date=2015-08-18 build_platform=x86_64-unknown-linux-gnu libgis_revision=64733 libgis_date=2015-02-25 01:56:29 +0100 (Wed, 25 Feb 2015) thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz issue: no visual output
On Thu, Aug 20, 2015 at 2:08 PM, Anna Petrášová kratocha...@gmail.com wrote: On Thu, Aug 20, 2015 at 7:11 AM, Markus Neteler nete...@osgeo.org wrote: ... - show map in wxGUI: ok - 3D view: white No error message. I tried to adjust the view parameters but no way... I assume you wanted to display the dem with the flowacc draped over it? Yes. In this case you have to switch off the flowacc layer because it's not a surface - you set it as color of the dem surface. ah, right. I guess I'll never learn that ;-) If you leave flowacc there, it tries to display it as a surface, but flowacc has crazy high values and the display can't really show it. If you tweak vertical ex. and height long enough you can eventually display it. OK - in this case, could wxNVIZ print a message that xyz map has a too large value range to be displayed as surface ? Then I would rather immediately realize that I loaded the wrong map. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxNviz rendering order problem
Hi, I have recently noticed strange behavior of wxNviz, for example vector layer is always visible even if I use negative z coordinate and it should be hidden below a surface. Probably, it is connected to newer wxPython version I started to use recently (2.8.12, so it's actually not new at all). According to the discussion [1], I tried these lines: Index: nviz/mapwindow.py === --- nviz/mapwindow.py (revision 55276) +++ nviz/mapwindow.py (working copy) @@ -72,8 +72,10 @@ def __init__(self, parent, id = wx.ID_ANY, Map = None, tree = None, lmgr = None): self.parent = parent # MapFrame -glcanvas.GLCanvas.__init__(self, parent, id) +from wx.glcanvas import WX_GL_DEPTH_SIZE +attribs=[WX_GL_DEPTH_SIZE,16,0] +glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs) MapWindow.__init__(self, parent, id, Map, tree, lmgr) which solved the problem. So, I would like to know if someone noticed this problem on other platforms than Linux. It's not clear to me if these lines are harmless or not for other platforms and if the number of the WX_GL_DEPTH_SIZE (= 16) can be used safely (probably different number works on different computers, see also [2]). Thanks for any info, Anna [1] http://wxpython-users.1045709.n5.nabble.com/OpenGL-depth-buffer-deosn-t-seem-to-work-in-wx-glcanvas-td5714984.html#a5714991 [2] http://stackoverflow.com/questions/14715739/how-can-i-determine-the-max-allowable-wx-gl-depth-size-for-a-wx-glcanvas ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxNviz rendering order problem
Anna, I have not noticed this particular problem on the Mac and I DO use wxPython 2.8.12. I've noticed a different issue of vector colors, but not this. I will try to recompile with these changes and see if it makes any difference in anything. 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 Mar 3, 2013, at 1:00 PM, grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org wrote: From: Anna Kratochvílová kratocha...@gmail.commailto:kratocha...@gmail.com Subject: [GRASS-dev] wxNviz rendering order problem Date: March 3, 2013 11:46:21 AM MST To: GRASS-dev grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org, Helena Mitasova hmit...@ncsu.edumailto:hmit...@ncsu.edu, Glynn Clements gl...@gclements.plus.commailto:gl...@gclements.plus.com Hi, I have recently noticed strange behavior of wxNviz, for example vector layer is always visible even if I use negative z coordinate and it should be hidden below a surface. Probably, it is connected to newer wxPython version I started to use recently (2.8.12, so it's actually not new at all). According to the discussion [1], I tried these lines: Index: nviz/mapwindow.py === --- nviz/mapwindow.py (revision 55276) +++ nviz/mapwindow.py (working copy) @@ -72,8 +72,10 @@ def __init__(self, parent, id = wx.ID_ANY, Map = None, tree = None, lmgr = None): self.parent = parent # MapFrame -glcanvas.GLCanvas.__init__(self, parent, id) +from wx.glcanvas import WX_GL_DEPTH_SIZE +attribs=[WX_GL_DEPTH_SIZE,16,0] +glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs) MapWindow.__init__(self, parent, id, Map, tree, lmgr) which solved the problem. So, I would like to know if someone noticed this problem on other platforms than Linux. It's not clear to me if these lines are harmless or not for other platforms and if the number of the WX_GL_DEPTH_SIZE (= 16) can be used safely (probably different number works on different computers, see also [2]). Thanks for any info, Anna [1] http://wxpython-users.1045709.n5.nabble.com/OpenGL-depth-buffer-deosn-t-seem-to-work-in-wx-glcanvas-td5714984.html#a5714991 [2] http://stackoverflow.com/questions/14715739/how-can-i-determine-the-max-allowable-wx-gl-depth-size-for-a-wx-glcanvas ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz rendering order problem
I just tried this, and it turns out that I DO get the same result you do. Also, trying to view any 3D vector in nviz gives the following error: Starting 3D view mode... Loading raster map elevation@PERMANENT... Loading raster map elevation@PERMANENT... Translating colors from raster map elevation@PERMANENT... Vector map firestations3D@grass7vect_sqlite loaded (7 points) No features from vector map firestations3D@grass7vect_sqlite fall within current region Error loading vector map firestations3D@grass7vect_sqlite Loading vector map firestations3D@grass7vect_sqlite (lines) failed Unfortunately, your fix does not work for me. Changing /nviz/mapwindow.py at line 76 to ... from wx.glcanvas import WX_GL_DEPTH_SIZE attribs=[WX_GL_DEPTH_SIZE,16,0] glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs) ...breaks nviz entirely. Even rasters won't display after this code change. Here is the error in the console: glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs) File /Applications/GRASS/GRASS-7.0.app/Contents/MacOS/etc /python/wx/glcanvas.py, line 103, in __init__ _glcanvas.GLCanvas_swiginit(self,_glcanvas.new_GLCanvas(*arg s, **kwargs)) wx._core . PyAssertionError : C++ assertion fmt failed at /BUILD/wxPython- src-2.8.12.1/src/mac/carbon/glcanvas.cpp(228) in Create(): Couldn't create OpenGl pixel format The terminal window gives a different error: Exception AttributeError: 'GLWindow' object has no attribute 'timerAnim' in bound method GLWindow.__del__ of nviz.mapwindow.GLWindow; ignored I'm using GRASS 7 r55179 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 Mar 3, 2013, at 1:24 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: Anna, I have not noticed this particular problem on the Mac and I DO use wxPython 2.8.12. I've noticed a different issue of vector colors, but not this. I will try to recompile with these changes and see if it makes any difference in anything. 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.eduhttp://csdc.asu.edu/ On Mar 3, 2013, at 1:00 PM, grass-dev-requ...@lists.osgeo.orgmailto:grass-dev-requ...@lists.osgeo.org wrote: From: Anna Kratochvílová kratocha...@gmail.commailto:kratocha...@gmail.com Subject: [GRASS-dev] wxNviz rendering order problem Date: March 3, 2013 11:46:21 AM MST To: GRASS-dev grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org, Helena Mitasova hmit...@ncsu.edumailto:hmit...@ncsu.edu, Glynn Clements gl...@gclements.plus.commailto:gl...@gclements.plus.com Hi, I have recently noticed strange behavior of wxNviz, for example vector layer is always visible even if I use negative z coordinate and it should be hidden below a surface. Probably, it is connected to newer wxPython version I started to use recently (2.8.12, so it's actually not new at all). According to the discussion [1], I tried these lines: Index: nviz/mapwindow.py === --- nviz/mapwindow.py (revision 55276) +++ nviz/mapwindow.py (working copy) @@ -72,8 +72,10 @@ def __init__(self, parent, id = wx.ID_ANY, Map = None, tree = None, lmgr = None): self.parent = parent # MapFrame -glcanvas.GLCanvas.__init__(self, parent, id) +from wx.glcanvas import WX_GL_DEPTH_SIZE +attribs=[WX_GL_DEPTH_SIZE,16,0] +glcanvas.GLCanvas.__init__(self, parent, id, attribList=attribs) MapWindow.__init__(self, parent, id, Map, tree, lmgr) which solved the problem. So, I would like to know if someone noticed this problem on other platforms than Linux. It's not clear to me if these lines are harmless or not for other platforms and if the number of the WX_GL_DEPTH_SIZE (= 16) can be used safely (probably different number works on different computers, see also [2]). Thanks for any info, Anna [1] http://wxpython-users.1045709.n5.nabble.com/OpenGL-depth-buffer-deosn-t-seem-to-work-in-wx-glcanvas-td5714984.html#a5714991 [2] http://stackoverflow.com/questions/14715739/how-can-i-determine-the-max-allowable-wx-gl-depth-size-for-a-wx-glcanvas ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz in 65, some clarification
Anna, thank you for backporting wxnviz, I just compiled it and it runs great, even with some highly specialized data (e.g. terrestrial lidar scans at 0.01m resolution). There are few things that still have issues (mostly features that never really worked in nviz and may be only Mac related) General - when I go from 3D view to 2D and then back to 3D I lose most of my settings (viewing position, zexag, fringe size etc. - this would be OK if I could get a warning and question whether I want to save my 3D viewing state before switching) - similarly, when I add volume to Map layers I lose my view settings and the 3D view goes back to default I think I found at least part of the problem - I tried saving my settings to m.nviz.image and the command saved zexag=0 although mine is set to 0.3, I got 2 when I set it to 2.3. Looking at the gxw file it is also saved z-exag as integer 0. Changing it to FP should fix it. z-exag value0/value min0/min max10/max original1/original /z-exag Volumes: - change of region by g.region seems to be ignored (or I missed something), I had to restart GRASS with the new region to get the 3D region for volumes right. Given that the default top, botom is 1,0, if GRASS starts with the default 3D region settings volumes do not work because there is just one level. - isosurfaces work with my terrestrial lidar data but the slices don't, it seems that it is due my resolution being 0.3m, when I change it to 1m I get at least some limited slicing I am pretty sure it is the resolution - perhaps integers cutting 0.3 to 0 somewhere. Here is my slice when my res3 is set to 1 - it works perfectly and the new controls are much easier to use http://skagit.meas.ncsu.edu/~helena/measwork/umstead/bank1_08_24_11_DTF_eldiff_timeslice9.png when I set my res3 to higher resolution, the slices do not show up. the image is eroding stream bank, so that is why the surface is vertical. Helena ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxNviz toolbar
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 attachment: nviz_toolbar.jpg___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Hello, There are still a few issues - levels for isosurfaces need to be floating point - now, if I set it to 0.5 I get 0 I changed spinctrl to floatspin, it's not available in older versions of wx (not sure about Mac), so try it. If floatspin is not available, spinctrl is used - redraw is not working automatically - I need to change view to get redraw (similar to what we had for 2D raster surfaces) It works for me. When exactly does this happen? It sometimes takes a few seconds to draw the isosurfaces. - I think the emission parameter can be removed Done. When working with two volumes (I will include several volumes in the test data set for you to try this out): - when second volume is added the list of isosurfaces needs to be cleared, it becomes all mixed up - I can get several levels with the same value and it is not clear to which volume which applies It should work now. - isosurfaces for second volume stay black even after I changed color to constant red (it looks like they don't get any light) I cannot confirm it. Although one side of isosurface is quite dark, the other is illuminated. I added the toggle normal direction feature, try if this helps. - after switching off the second volume in map layers it disapears but when I switch it back on and define isosurface for it, the isosurfaces do not come back. Hopefully fixed. - volumes need position control similar to the surfaces - e.g. I have isosurfaces from two volumes and I need to view them both overlayed and separated (e.g. above each other - to see the spatial relationship I added this functionality. It is the same as for surfaces. I will try volumes on Vasek's computer which had some similar problems as yours (although it's not Mac), so maybe I will find out the problems you mentioned. Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Helena, On Jul 4, 2011, at 4:20 PM, Helena Mitasova wrote: On Jul 4, 2011, at 3:39 PM, Michael Barton wrote: Anna, I did some further testing. SVN from the past hour. 1) Volumes. These loaded OK. When I move them around in the view, I can see the bounding cube. But I can't see any isosurfaces Mike, make sure that you set the value of your isosurface, then add it and set polygon resolution to 1 - I have the isosurfaces loading at 3 and only very little shows up, but they pop-up at full resolution. Also your isosurfaces may be under your surface (if you have any), you would have to change the surface position for now, as the position is not implemented for volumes yet. Finally, make sure you have the 3D region set up correctly - I find it rather tricky now when we have res3 for all and you need to over ride it by tbres if you want different resolution vertically. 3D region setting may need some tune up. Well, for this reason, I was testing in a mapset where I'd done 3D work previously and had it displayed with the old NVIZ. But I'll look more closely at all the settings to make sure that it's OK. or slides (slices?). this might not have been implemented yet. Maybe I'm doing something wrong, but nothing appears no matter how I set it. 2) Fringe. I was able to get the height to update on my SRTM of the Jordan River valley, but cannot see any changes at all when I apply it to the Spearfish 10m DEM. Also, there are some places where the top does not match the topography. I'm attaching an image from the Spearfish elevation10m DEM to illustrate what I'm talking about. The top edge of the fringe follows the topography in some places, but cuts from a peak to a place in a valley (not the bottom) to the left of the peak. This may be an OpenGL issue, but should be looked into for this to be useful. the bad top edge of the fringe has been there from the very beginning - it may be computed based on coarse resolution - it may be worth to check whether it is still a problem with a very small DEM when everything is loaded at resolution 1. But it may be something entirely different and goes beyond wxnviz. Of course it would be great to find a fix. 3) Graphic output (follow up on Hamish's post of earlier today). It works!! That is good. But it only seems to work for PPM. The Tif file that it creates will not open (tried in GIMP and Apple Preview). I can open the saved tif with Preview It gave me an error. I remember this happening before. It turns out that the tif file is really a ppm. If I change the extension to *.ppm it open fine in GIMP and Graphic Convertor. As Hamish notes, other formats would be welcome--jpeg and png especially. yes, especially for MSWindows users without tiff support. 4) Your point is well taken about adjusting one image versus adjusting all of them. But I'll make one more pitch for putting position onto the view page. It moves around images in the window to position them in different ways. This is what happens in the view window. Perhaps I'm unusual in this, but when I'm positioning the images (i.e., with the position tool), I also want to move them around with the view puck, adjust height, etc. When I'm changing image display properties (drape map, transparency, resolution, etc.), I'm less likely to be messing with positioning. But that's just me. How do others normally work with 3D images? I haven't looked into this. I will try it next. I'm not getting the terminal chatter that Markus reported. Maybe it's been fixed in the interim. The only thing I get is the following when I launch GRASS Launching 'wxpython' GUI in the background, please wait... GRASS 7.0.svn (Spearfish60_test):~ Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 ...and the following when I quite the GUI after running wxNviz pythonw2.6(3540,0xa070e540) malloc: *** error for object 0x21d0d980: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug that is what I am getting too but it is not causing any problems. Right. Michael Helena Thanks again. This is really looking good. Haw hard is a north arrow? 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:
Re: [GRASS-dev] wxNviz volumes
Hi,
2011/7/2 Helena Mitasova hmit...@ncsu.edu:
Traceback (most recent call last):
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/toolbars.py, line
1353, in OnNvizCmd
self.lmgr.GetLogWindow().WriteLog(text = cmd, switchPage =
True)
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
385, in WriteLog
self.cmd_output.SetStyle()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
1019, in SetStyle
settings = preferences.Settings()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/preferences.py,
line 64, in __init__
self.filePath = os.path.join(utils.GetSettingsPath(), 'wx')
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/utils.py, line
759, in GetSettingsPath
version = int(grass.version()['version'].split('.', 1)[0])
KeyError
:
'version'
it's not related, hopefully fixed in r46949.
Martin
--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Anna, I did some further testing. SVN from the past hour. 1) Volumes. These loaded OK. When I move them around in the view, I can see the bounding cube. But I can't see any isosurfaces or slides (slices?). Maybe I'm doing something wrong, but nothing appears no matter how I set it. 2) Fringe. I was able to get the height to update on my SRTM of the Jordan River valley, but cannot see any changes at all when I apply it to the Spearfish 10m DEM. Also, there are some places where the top does not match the topography. I'm attaching an image from the Spearfish elevation10m DEM to illustrate what I'm talking about. The top edge of the fringe follows the topography in some places, but cuts from a peak to a place in a valley (not the bottom) to the left of the peak. This may be an OpenGL issue, but should be looked into for this to be useful. 3) Graphic output (follow up on Hamish's post of earlier today). It works!! That is good. But it only seems to work for PPM. The Tif file that it creates will not open (tried in GIMP and Apple Preview). As Hamish notes, other formats would be welcome--jpeg and png especially. 4) Your point is well taken about adjusting one image versus adjusting all of them. But I'll make one more pitch for putting position onto the view page. It moves around images in the window to position them in different ways. This is what happens in the view window. Perhaps I'm unusual in this, but when I'm positioning the images (i.e., with the position tool), I also want to move them around with the view puck, adjust height, etc. When I'm changing image display properties (drape map, transparency, resolution, etc.), I'm less likely to be messing with positioning. But that's just me. How do others normally work with 3D images? I'm not getting the terminal chatter that Markus reported. Maybe it's been fixed in the interim. The only thing I get is the following when I launch GRASS Launching 'wxpython' GUI in the background, please wait... GRASS 7.0.svn (Spearfish60_test):~ Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 ...and the following when I quite the GUI after running wxNviz pythonw2.6(3540,0xa070e540) malloc: *** error for object 0x21d0d980: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Thanks again. This is really looking good. Haw hard is a north arrow? 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 Jul 3, 2011, at 5:10 AM, Anna Kratochvílová wrote: Hello, Martin's fix allowed me to get wxNviz going and try it out. Your summer work has make great improvements in getting this to the level of functionality of the old tcltk nviz. The view controls work very well and the map updates automatically. The data controls work well too and alter the image as indicated. The lighting works really well too and I'm glad to see the cutting plane and fringe functional. This is all very much appreciated. I have a few observations and suggestions from going through and testing. 1. Position controls. Works fine. But this seems to make more sense on the view page as it affects the orientation of the map display rather than the color or character of the image itself (other things on the data page). On data page there are things relating to one chosen map, so that's the reason why position is there. But I agree it should be improved. I thought about some interactive positioning, I'm not sure how this could be done but I'll try something. 2. Z-exag. Works fine. It would be nice if this could be a float with at least 1 decimal so that z-exag. of 1.5 or 2.5 could be set. Not a high priority though. This shouldn't be problem. 3. Cutting plane. Most works fine. But the x and y sliders seem to do the same thing. Height doesn't seem to have any affect. Tilt make visual cutting planes disappear (same thing with TclTk). x, y mean the rotation center, you can see it when you use rotation. Height has effect only when using tilt. I know about the disappearing of the shading with tilt but I'm not sure if I can do anything about it. 4. Fringe. All works well except the 'elevation from bottom'
Re: [GRASS-dev] wxNviz volumes
On Jul 4, 2011, at 3:39 PM, Michael Barton wrote: Anna, I did some further testing. SVN from the past hour. 1) Volumes. These loaded OK. When I move them around in the view, I can see the bounding cube. But I can't see any isosurfaces Mike, make sure that you set the value of your isosurface, then add it and set polygon resolution to 1 - I have the isosurfaces loading at 3 and only very little shows up, but they pop-up at full resolution. Also your isosurfaces may be under your surface (if you have any), you would have to change the surface position for now, as the position is not implemented for volumes yet. Finally, make sure you have the 3D region set up correctly - I find it rather tricky now when we have res3 for all and you need to over ride it by tbres if you want different resolution vertically. 3D region setting may need some tune up. or slides (slices?). this might not have been implemented yet. Maybe I'm doing something wrong, but nothing appears no matter how I set it. 2) Fringe. I was able to get the height to update on my SRTM of the Jordan River valley, but cannot see any changes at all when I apply it to the Spearfish 10m DEM. Also, there are some places where the top does not match the topography. I'm attaching an image from the Spearfish elevation10m DEM to illustrate what I'm talking about. The top edge of the fringe follows the topography in some places, but cuts from a peak to a place in a valley (not the bottom) to the left of the peak. This may be an OpenGL issue, but should be looked into for this to be useful. the bad top edge of the fringe has been there from the very beginning - it may be computed based on coarse resolution - it may be worth to check whether it is still a problem with a very small DEM when everything is loaded at resolution 1. But it may be something entirely different and goes beyond wxnviz. Of course it would be great to find a fix. 3) Graphic output (follow up on Hamish's post of earlier today). It works!! That is good. But it only seems to work for PPM. The Tif file that it creates will not open (tried in GIMP and Apple Preview). I can open the saved tif with Preview As Hamish notes, other formats would be welcome--jpeg and png especially. yes, especially for MSWindows users without tiff support. 4) Your point is well taken about adjusting one image versus adjusting all of them. But I'll make one more pitch for putting position onto the view page. It moves around images in the window to position them in different ways. This is what happens in the view window. Perhaps I'm unusual in this, but when I'm positioning the images (i.e., with the position tool), I also want to move them around with the view puck, adjust height, etc. When I'm changing image display properties (drape map, transparency, resolution, etc.), I'm less likely to be messing with positioning. But that's just me. How do others normally work with 3D images? I haven't looked into this. I will try it next. I'm not getting the terminal chatter that Markus reported. Maybe it's been fixed in the interim. The only thing I get is the following when I launch GRASS Launching 'wxpython' GUI in the background, please wait... GRASS 7.0.svn (Spearfish60_test):~ Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 Mon Jul 4 12:14:16 cmb-MBP-3.local pythonw2.6[3540] Error: CGContextRestoreGState: invalid context 0x0 ...and the following when I quite the GUI after running wxNviz pythonw2.6(3540,0xa070e540) malloc: *** error for object 0x21d0d980: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug that is what I am getting too but it is not causing any problems. Helena Thanks again. This is really looking good. Haw hard is a north arrow? 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 Jul 3, 2011, at 5:10 AM, Anna Kratochvílová wrote: Hello, Martin's fix allowed me to get wxNviz going and try it out. Your summer work has make great improvements in getting this to the level of functionality of the old tcltk nviz. The view controls work very well and the map updates automatically. The data controls work well too and alter the image as
Re: [GRASS-dev] wxNviz volumes
Hello,
There are still a few issues
- levels for isosurfaces need to be floating point - now, if I set it to 0.5 I
get 0
- redraw is not working automatically - I need to change view to get redraw
(similar to what we had for 2D raster surfaces)
- I think the emission parameter can be removed
When working with two volumes (I will include several volumes in the test data
set
for you to try this out):
- when second volume is added the list of isosurfaces needs to be cleared,
it becomes all mixed up - I can get several levels with the same value and
it is not clear to which volume which applies
- isosurfaces for second volume stay black even after I changed color to
constant red
(it looks like they don't get any light)
- after switching off the second volume in map layers it disapears but when I
switch it back on
and define isosurface for it, the isosurfaces do not come back.
- volumes need position control similar to the surfaces - e.g. I have
isosurfaces from two volumes
and I need to view them both overlayed and separated (e.g. above each other -
to see the spatial relationship
I will look at this week.
when I click on the Generate command for nviz_cmd nothing happens, here is the
traceback:
Traceback (most recent call last):
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/toolbars.py, line
1353, in OnNvizCmd
self.lmgr.GetLogWindow().WriteLog(text = cmd, switchPage =
True)
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
385, in WriteLog
self.cmd_output.SetStyle()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
1019, in SetStyle
settings = preferences.Settings()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/preferences.py,
line 64, in __init__
self.filePath = os.path.join(utils.GetSettingsPath(), 'wx')
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/utils.py, line
759, in GetSettingsPath
version = int(grass.version()['version'].split('.', 1)[0])
KeyError
:
'version'
I have no idea why it doesn't work for you. It seems to me that you must have
similar problems
whenever something is written to command output. I noticed some recent changes
in r46915 done by Martin,
which could be related with this problem (could you look at it Martin please?).
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Hello, Martin's fix allowed me to get wxNviz going and try it out. Your summer work has make great improvements in getting this to the level of functionality of the old tcltk nviz. The view controls work very well and the map updates automatically. The data controls work well too and alter the image as indicated. The lighting works really well too and I'm glad to see the cutting plane and fringe functional. This is all very much appreciated. I have a few observations and suggestions from going through and testing. 1. Position controls. Works fine. But this seems to make more sense on the view page as it affects the orientation of the map display rather than the color or character of the image itself (other things on the data page). On data page there are things relating to one chosen map, so that's the reason why position is there. But I agree it should be improved. I thought about some interactive positioning, I'm not sure how this could be done but I'll try something. 2. Z-exag. Works fine. It would be nice if this could be a float with at least 1 decimal so that z-exag. of 1.5 or 2.5 could be set. Not a high priority though. This shouldn't be problem. 3. Cutting plane. Most works fine. But the x and y sliders seem to do the same thing. Height doesn't seem to have any affect. Tilt make visual cutting planes disappear (same thing with TclTk). x, y mean the rotation center, you can see it when you use rotation. Height has effect only when using tilt. I know about the disappearing of the shading with tilt but I'm not sure if I can do anything about it. 4. Fringe. All works well except the 'elevation from bottom' command. It doesn't seem to do anything. It works for me. Maybe it's another Mac problem. Thanks for testing, it's welcomed. Best regards Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
nviz_cmd now compiles on Mac (was Re: [GRASS-dev] wxNviz volumes)
Just an update - nviz_cmd now compiles on Mac, I think r46942 fixed it. The output command works well and opens a lot of possibilities for creating dynamic visualizations. Thanks to all who figured this out, Helena when I click on the Generate command for nviz_cmd nothing happens, here is the traceback: I have no idea why it doesn't work for you. It seems to me that you must have similar problems whenever something is written to command output. I noticed some recent changes in r46915 done by Martin, which could be related with this problem (could you look at it Martin please?). Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: nviz_cmd now compiles on Mac (was Re: [GRASS-dev] wxNviz volumes)
Helena wrote: The output command works well and opens a lot of possibilities for creating dynamic visualizations. would that include updating the raster map name between keyframes? e.g. for showing a 3D time series with 100+ iterations. (too many to manually enter in efficiently) thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
On Jul 2, 2011, at 7:35 AM, Anna Kratochvílová wrote: Hello Helena, - I tried volumes in wxnviz but I did not get too far - the GUI does not see any of my 3d rasters - the browser for 3D raster maps shows the mapsets but nothing in them It should be ok now. It still does not work for me - when I am setting the 3D region (from set region to match this 3D raster) they show up, but not when I try to add it under wxnvizVolume. Am I missing something? Should I be adding them as map layers first somewhere? 3D raster must be loaded from the layer manager toolbar first like any other maps do. In wxnviz only loaded maps (in Map layers tab) are offered. You tried this and it still doesn't work? Maybe I'm missing something. I was able to find just the Slovakia3D dataset. Could you tell me where I can find any other volumes for better testing? I am working on a new one but I got into some troubles when I tried to extend the data set and use mask. Meanwhile you can try this: get this raster time series mapset and put it into nc_spm_08 http://courses.ncsu.edu/mea582/common/media/01/NagsHead_series.zip then generate a space-time cube representation of the time series for a small subregion: g.region n=250416 s=249942 w=913734 e=914022 t=40 b=12 nsres=2 ewres=2 res3=2 tbres=4 -ap3 r.to.rast3 in=NH_1999_1m,NH_2001_1m,NH_2004_1m,NH_2005_1m,NH_2007_1m,NH_2008_1m out=NH_99_08_stack #check your values r3.info NH_99_08_stack you can then use elevation raster NH_2008_1m in combination with with NH_99_08_stack to test everything for a single volume (isosurfaces 6, 10, 12 work well) to generate second volume for testing over little bit larger area (I had to quit grass when changing computational region because the 3d view was stuck with the previous region and I could not find a way to get it to update to the new region) g.region rast=NH_1999_1m t=40 b=12 tbres=4 -p3 r.to.rast3 in=NH_1999_1m,NH_2001_1m,NH_2004_1m,NH_2005_1m,NH_2007_1m,NH_2008_1m out=NH_99_08_largestack r3.info NH_99_08_largestack you can then use NH_2008_1m in combination with with NH_99_08_stack and NH_99_08_largestack to test handling of two volumes. You will note that whichever volume you you have loaded a second one, it will draw the isosurfaces in black - I think they are not illuminated. Let me know if something is not clear, it is still a little bit tricky but it works, I would like to ask if the new feature - generating commands for nviz_cmd is ok or if the interface should look differently (where the output should be written etc.). So if you have some ideas please tell me. it is good as is right now, I think users can write scripts on their own to run the command through series of raster maps to generate the dynamic surfaces. Of course, GUI would be helpful but I would leave it after wxnviz core functionality runs well. One issue came to mind when looking at the command (I think this was already discussed before) - would it be possible to replace the ppm output with png or other more common format? Helena Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Helena wrote: One issue came to mind when looking at the command (I think this was already discussed before) - would it be possible to replace the ppm output with png or other more common format? in the tcl/tk version of NVIZ it is done that way due to the lack of support for other formats, unless we add external dependencies and system() calls which are not very portable. (maybe just PPM GIF are allowed directly from tcl/tk?) the Wx version shouldn't be limited by that. rough memory, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
On Jul 1, 2011, at 11:59 PM, Hamish wrote: Helena wrote: It is crossections - we called them slices because you are slicing through the volume but I guess that cross-sections is a more appropriate term - I have a few examples here: http://skagit.meas.ncsu.edu/~helena/publwork/MitSTCfigs2.ppt It is pretty important part of volume visualization. Hi, slightly off-topic, but something I've been wondering about- do you have any good strategies for semi-automatically choosing isosurface levels? or do you just pick them by eye? for isosurfaces and volume in general you really need to display them interactively so that you can see them from all sides and switch isosurfaces on and off basedon which level you are interested in and slice thruogh the volume. For presentations, we have been using animations like these browsing through isosurface levels: http://skagit.meas.ncsu.edu/~helena/measwork/nc_coast/NHiso.gif http://skagit.meas.ncsu.edu/~helena/measwork/nc_coast/oi_iso.gif http://skagit.meas.ncsu.edu/~helena/measwork/nc_coast/oi_isoS.gif (I use gifs here because they are so easy to generate, but movie formats such as quicktime or mpg that have viewer that allows you to browse through the frames and stop where you want to show something interesting is better), decorations such as legend with pointer will also help If movie is not an option, for one of our publications, I included a set of images - each isosurface value in a separate image: http://skagit.meas.ncsu.edu/~helena/publwork/jcrbhi/JCRfig6_isosurfacesF.tif These are some older volume movies by Bill Brown (they play little too fast on todays machines but you can browse through them) http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/movie/phb.mpg http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/movie/codbox.mpg http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/movie/phslice2.mpg they are explained here (still a draft document, after more than 12 years) http://skagit.meas.ncsu.edu/~helena/gmslab/gsoils/ccsoil2.html Depending on your data generating the isosurfaces using -e or ln may help, at least for static figures. Browsing through the volumes should be much easier with wxnviz that saves settings into nviz_cmd command, so one can just loop the the isosurface values or crossection coordinates to generate the frames for the movie. Helena perhaps 9 slices by histogram of values? r3.univar precentile=`seq -s, 5 10 95` ? or is a linear split like for standard 2D contour lines less confusing for the viewer to understand? (I'm working with heavily vertically stratified data and the linear approach isn't working very well) thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Hello Helena, - I tried volumes in wxnviz but I did not get too far - the GUI does not see any of my 3d rasters - the browser for 3D raster maps shows the mapsets but nothing in them It should be ok now. It still does not work for me - when I am setting the 3D region (from set region to match this 3D raster) they show up, but not when I try to add it under wxnvizVolume. Am I missing something? Should I be adding them as map layers first somewhere? 3D raster must be loaded from the layer manager toolbar first like any other maps do. In wxnviz only loaded maps (in Map layers tab) are offered. You tried this and it still doesn't work? Maybe I'm missing something. I was able to find just the Slovakia3D dataset. Could you tell me where I can find any other volumes for better testing? I would like to ask if the new feature - generating commands for nviz_cmd is ok or if the interface should look differently (where the output should be written etc.). So if you have some ideas please tell me. Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
On Jul 2, 2011, at 7:35 AM, Anna Kratochvílová wrote:
Hello Helena,
- I tried volumes in wxnviz but I did not get too far - the GUI does not
see
any
of my 3d rasters -
the browser for 3D raster maps shows the mapsets but nothing in them
It should be ok now.
It still does not work for me - when I am setting the 3D region (from set
region
to match this 3D raster) they show up,
but not when I try to add it under wxnvizVolume. Am I missing something?
Should
I be adding them as map layers
first somewhere?
3D raster must be loaded from the layer manager toolbar first like any other
maps do.
In wxnviz only loaded maps (in Map layers tab) are offered. You tried this
and it still doesn't work?
Maybe I'm missing something.
I finally remembered the button where to add it - it is working now:
There are still a few issues
- levels for isosurfaces need to be floating point - now, if I set it to 0.5 I
get 0
- redraw is not working automatically - I need to change view to get redraw
(similar to what we had for 2D raster surfaces)
- I think the emission parameter can be removed
When working with two volumes (I will include several volumes in the test data
set
for you to try this out):
- when second volume is added the list of isosurfaces needs to be cleared,
it becomes all mixed up - I can get several levels with the same value and
it is not clear to which volume which applies
- isosurfaces for second volume stay black even after I changed color to
constant red
(it looks like they don't get any light)
- after switching off the second volume in map layers it disapears but when I
switch it back on
and define isosurface for it, the isosurfaces do not come back.
- volumes need position control similar to the surfaces - e.g. I have
isosurfaces from two volumes
and I need to view them both overlayed and separated (e.g. above each other -
to see the spatial relationship
I was able to find just the Slovakia3D dataset. Could you tell me where I can
find any other volumes
for better testing?
I will post a mapset with some data in a day or two, I just need to clean it up.
I would like to ask if the new feature - generating commands for nviz_cmd is
ok or if the interface should look
differently (where the output should be written etc.). So if you have some
ideas please tell me.
when I click on the Generate command for nviz_cmd nothing happens, here is the
traceback:
Traceback (most recent call last):
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/toolbars.py, line
1353, in OnNvizCmd
self.lmgr.GetLogWindow().WriteLog(text = cmd, switchPage =
True)
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
385, in WriteLog
self.cmd_output.SetStyle()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/goutput.py, line
1019, in SetStyle
settings = preferences.Settings()
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/preferences.py,
line 64, in __init__
self.filePath = os.path.join(utils.GetSettingsPath(), 'wx')
File /Users/helena/grassdev7/grass_trunk/dist.i386-apple-
darwin10.7.0/etc/gui/wxpython/gui_modules/utils.py, line
759, in GetSettingsPath
version = int(grass.version()['version'].split('.', 1)[0])
KeyError
:
'version'
Helena
Anna
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Hi Anna, Martin's fix allowed me to get wxNviz going and try it out. Your summer work has make great improvements in getting this to the level of functionality of the old tcltk nviz. The view controls work very well and the map updates automatically. The data controls work well too and alter the image as indicated. The lighting works really well too and I'm glad to see the cutting plane and fringe functional. This is all very much appreciated. I have a few observations and suggestions from going through and testing. 1. Position controls. Works fine. But this seems to make more sense on the view page as it affects the orientation of the map display rather than the color or character of the image itself (other things on the data page). 2. Z-exag. Works fine. It would be nice if this could be a float with at least 1 decimal so that z-exag. of 1.5 or 2.5 could be set. Not a high priority though. 3. Cutting plane. Most works fine. But the x and y sliders seem to do the same thing. Height doesn't seem to have any affect. Tilt make visual cutting planes disappear (same thing with TclTk). 4. Fringe. All works well except the 'elevation from bottom' command. It doesn't seem to do anything. I'll check on the volumes next. Thanks for all your work. 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 Jul 1, 2011, at 8:54 PM, grass-dev-requ...@lists.osgeo.org wrote: Date: Fri, 1 Jul 2011 23:16:22 -0400 From: Helena Mitasova hmit...@ncsu.edu Subject: Re: [GRASS-dev] wxNviz volumes To: Anna Kratochv?lov? kratocha...@seznam.cz Cc: Martin Landa landa.mar...@gmail.com, GRASS developers list grass-dev@lists.osgeo.org Message-ID: 6a39f8f7-9eb1-4151-9beb-69d8603f3...@ncsu.edu Content-Type: text/plain; charset=windows-1252 On Jul 1, 2011, at 10:00 AM, Anna Kratochv?lov? wrote: Hello, - I tried volumes in wxnviz but I did not get too far - the GUI does not see any of my 3d rasters - the browser for 3D raster maps shows the mapsets but nothing in them It should be ok now. It still does not work for me - when I am setting the 3D region (from set region to match this 3D raster) they show up, but not when I try to add it under wxnvizVolume. Am I missing something? Should I be adding them as map layers first somewhere? I haven't tested volumes yet, but I saw that slices are not implemented yet, is this another name for cross-sections or it's another functionality? It is crossections - we called them slices because you are slicing through the volume but I guess that cross-sections is a more appropriate term - I have a few examples here: http://skagit.meas.ncsu.edu/~helena/publwork/MitSTCfigs2.ppt It is pretty important part of volume visualization. - there appears to be an issue with automatic loading of raster when opening the Data Tab: -- I have map1 and map2 in GIS manager. -- I switch off map1 but I keep map2 on -- switch view to 3d. -- wxnviz opens correctly with map2 -- when I switch to tab Data, map1 is loaded as raster map - I would have expected map2 --I tried with more rasters and it looks like it always picks up the raster that was added the first (it is lowest in the list) rather than the one which is highlighted I tried to fix this. Loading and unloading maps is a bit tricky and I'm afraid there are more such bugs. this works now for various combinations and multiple surfaces as well -nviz2/cmd does not compile, when I run make on it I get the following /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:503: error: redefinition of ?struct Rect? lipo: can't figure out the architecture type of: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//ccw2Iwjp.out make: *** [OBJ.i386-apple-darwin10.7.0/vector.o] Error 1 nviz does not compile either ( I have some issue with my TclTk ), perhaps that is causing problems with nviz_cmd? . Nviz_cmd is not connected with TclTk. Concerning the problem with compilation I'm afraid I cannot help. It might be connected with the changes in nviz_cmd vectors done by Martin recently and I'm sure he would now better how this could be solved. OK, I will wait for this, it still complains about struct Rect /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:503: error: redefinition of ?struct Rect? lipo: can't figure out the architecture type of: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//cc4KN3CM.out make: *** [OBJ.i386-apple-darwin10.7.0/vector.o] Error 1 Thank you, Helena Best regards, Anna
Re: [GRASS-dev] wxNviz volumes
On Jul 1, 2011, at 10:00 AM, Anna Kratochvílová wrote: Hello, - I tried volumes in wxnviz but I did not get too far - the GUI does not see any of my 3d rasters - the browser for 3D raster maps shows the mapsets but nothing in them It should be ok now. It still does not work for me - when I am setting the 3D region (from set region to match this 3D raster) they show up, but not when I try to add it under wxnvizVolume. Am I missing something? Should I be adding them as map layers first somewhere? I haven't tested volumes yet, but I saw that slices are not implemented yet, is this another name for cross-sections or it's another functionality? It is crossections - we called them slices because you are slicing through the volume but I guess that cross-sections is a more appropriate term - I have a few examples here: http://skagit.meas.ncsu.edu/~helena/publwork/MitSTCfigs2.ppt It is pretty important part of volume visualization. - there appears to be an issue with automatic loading of raster when opening the Data Tab: -- I have map1 and map2 in GIS manager. -- I switch off map1 but I keep map2 on -- switch view to 3d. -- wxnviz opens correctly with map2 -- when I switch to tab Data, map1 is loaded as raster map - I would have expected map2 --I tried with more rasters and it looks like it always picks up the raster that was added the first (it is lowest in the list) rather than the one which is highlighted I tried to fix this. Loading and unloading maps is a bit tricky and I'm afraid there are more such bugs. this works now for various combinations and multiple surfaces as well -nviz2/cmd does not compile, when I run make on it I get the following /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:503: error: redefinition of ‘struct Rect’ lipo: can't figure out the architecture type of: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//ccw2Iwjp.out make: *** [OBJ.i386-apple-darwin10.7.0/vector.o] Error 1 nviz does not compile either ( I have some issue with my TclTk ), perhaps that is causing problems with nviz_cmd? . Nviz_cmd is not connected with TclTk. Concerning the problem with compilation I'm afraid I cannot help. It might be connected with the changes in nviz_cmd vectors done by Martin recently and I'm sure he would now better how this could be solved. OK, I will wait for this, it still complains about struct Rect /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:503: error: redefinition of ‘struct Rect’ lipo: can't figure out the architecture type of: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//cc4KN3CM.out make: *** [OBJ.i386-apple-darwin10.7.0/vector.o] Error 1 Thank you, Helena Best regards, Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxNviz volumes
Helena wrote: It is crossections - we called them slices because you are slicing through the volume but I guess that cross-sections is a more appropriate term - I have a few examples here: http://skagit.meas.ncsu.edu/~helena/publwork/MitSTCfigs2.ppt It is pretty important part of volume visualization. Hi, slightly off-topic, but something I've been wondering about- do you have any good strategies for semi-automatically choosing isosurface levels? or do you just pick them by eye? perhaps 9 slices by histogram of values? r3.univar precentile=`seq -s, 5 10 95` ? or is a linear split like for standard 2D contour lines less confusing for the viewer to understand? (I'm working with heavily vertically stratified data and the linear approach isn't working very well) thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxNviz volumes
Anna, more things to report: - I tried volumes in wxnviz but I did not get too far - the GUI does not see any of my 3d rasters - the browser for 3D raster maps shows the mapsets but nothing in them - there appears to be an issue with automatic loading of raster when opening the Data Tab: -- I have map1 and map2 in GIS manager. -- I switch off map1 but I keep map2 on -- switch view to 3d. -- wxnviz opens correctly with map2 -- when I switch to tab Data, map1 is loaded as raster map - I would have expected map2 --I tried with more rasters and it looks like it always picks up the raster that was added the first (it is lowest in the list) rather than the one which is highlighted -nviz2/cmd does not compile, when I run make on it I get the following /System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.framework/Headers/MacTypes.h:503: error: redefinition of ‘struct Rect’ lipo: can't figure out the architecture type of: /var/folders/-w/-wN910nTFamsDLR+fBkvBTI/-Tmp-//ccw2Iwjp.out make: *** [OBJ.i386-apple-darwin10.7.0/vector.o] Error 1 nviz does not compile either ( I have some issue with my TclTk ), perhaps that is causing problems with nviz_cmd? Helena On Jun 27, 2011, at 4:09 PM, Anna Kratochvílová wrote: Hello, I've just tried to fix the problems with light model and fringe, I hope it will work for you. I'm going to work on nviz_cmd now and with certain parameters I get segmantation fault. So it would be helpful if you could tell me about any bugs you are aware of and I'll try to fix them. Best regards Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz broken in 6.5 on Linux 64bit
Hi, 2010/8/30 Markus Neteler nete...@osgeo.org: 2010/8/30 Markus Metz markus.metz.gisw...@googlemail.com: Problem is ctypes, the Makefiles have been backported from trunk without adapting to the build system in 6.5. right, see http://trac.osgeo.org/grass/ticket/1125#comment:43 In the long run it might be better to backport the new Makefiles system from GRASS 7. It would also help for g.extension and the like. I would vote for minimalistic approach, ctypes will be probably backported to 6.4.x, any heavy changes are complicated in this regard. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz broken in 6.5 on Linux 64bit
Message: 3D view mode not available Reason: /lib/libz.so.1.2.3: wrong ELF class: ELFCLASS32 Note that the wxGUI's 3D view mode is currently disabled on MS Windows (hopefully this will be fixed soon). Please keep an eye out for updated versions of GRASS. In the meantime you can use NVIZ from the File menu. Problem is ctypes, the Makefiles have been backported from trunk without adapting to the build system in 6.5. in 6.5, lib/python/ctypes/nviz.py imports 34 libs: # Begin libraries _libs[grass_nviz] = load_library(grass_nviz) _libs[grass_bitmap] = load_library(grass_bitmap) _libs[grass_linkm] = load_library(grass_linkm) _libs[grass_g3d] = load_library(grass_g3d) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_vect] = load_library(grass_vect) _libs[grass_dbmibase] = load_library(grass_dbmibase) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_dbmiclient] = load_library(grass_dbmiclient) _libs[grass_dbmibase] = load_library(grass_dbmibase) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_dgl] = load_library(grass_dgl) _libs[grass_dig2] = load_library(grass_dig2) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_rtree] = load_library(grass_rtree) _libs[grass_gis] = load_library(grass_gis) _libs[grass_datetime] = load_library(grass_datetime) _libs[z] = load_library(z) _libs[grass_linkm] = load_library(grass_linkm) _libs[grass_rtree] = load_library(grass_rtree) # 34 libraries # End libraries in 7.0, lib/python/ctypes/nviz.py imports only one lib: # Begin libraries _libs[grass_nviz.7.0.svn] = load_library(grass_nviz.7.0.svn) # 1 libraries # End libraries The same applies to all other files generated in lib/python/ctypes The difference is caused by $(NVIZLIB) != $(NVIZLIB) between 6.5 and 7.0, same for all others in lib/python/ctypes/Makefile In 6.5 it should read something like date_LIBS = -l$(DATETIME_LIBNAME) etc. instead of date_LIBS = $(DATETIMELIB) More modifications might be necessary. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz broken in 6.5 on Linux 64bit
Hi, 2010/8/30 Markus Metz markus.metz.gisw...@googlemail.com: Problem is ctypes, the Makefiles have been backported from trunk without adapting to the build system in 6.5. right, see http://trac.osgeo.org/grass/ticket/1125#comment:43 Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz broken in 6.5 on Linux 64bit
On Mon, Aug 30, 2010 at 1:16 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/8/30 Markus Metz markus.metz.gisw...@googlemail.com: Problem is ctypes, the Makefiles have been backported from trunk without adapting to the build system in 6.5. right, see http://trac.osgeo.org/grass/ticket/1125#comment:43 In the long run it might be better to backport the new Makefiles system from GRASS 7. It would also help for g.extension and the like. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz broken in 6.5 on Linux 64bit
Hi, 2010/8/30 Hamish hamis...@yahoo.com: Markus Neteler wrote: In the long run it might be better to backport the new Makefiles system from GRASS 7. ctypes backport is quite important for wxGUI also in GRASS 6.5. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz on mac osx (grass7.0)
Hi, problems to get wx-nviz running on mac osx 10.6.4 building grass7.0 this the log : Finished compilation: Gio 19 Ago 2010 13:31:39 CEST make: *** [default] Error 1 MacBook-Pro-15-di-sasha:grass_trunk sasha$ cd /Users/sasha/gis/grass_trunk/visualization/nviz MacBook-Pro-15-di-sasha:nviz sasha$ make make -C src gcc -g -O2-arch i386 -arch x86_64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -D_FILE_OFFSET_BITS=64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -o OBJ.i386-apple-darwin10.4.0/togl.o -c togl.c In file included from togl.c:53: /usr/include/tkMacOSX.h:31: error: expected declaration specifiers or ‘...’ before ‘TkRegion’ togl.c:54:54: error: tkMacOSXInt.h: No such file or directory togl.c:265: error: expected specifier-qualifier-list before ‘XVisualInfo’ togl.c: In function ‘SetMacBufRect’: togl.c:1084: error: ‘TkWindow’ undeclared (first use in this function) togl.c:1084: error: (Each undeclared identifier is reported only once togl.c:1084: error: for each function it appears in.) togl.c:1084: error: expected expression before ‘)’ token togl.c:1088: warning: ‘GetPortBounds’ is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawAPI.h:4527) togl.c:1088: error: expected expression before ‘)’ token togl.c:1092: error: expected expression before ‘)’ token togl.c: In function ‘Togl_Cmd’: togl.c:1500: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:1500: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:1500: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:1501: error: ‘Togl’ has no member named ‘EpsMapSize’ togl.c: In function ‘Togl_CreateWindow’: togl.c:1764: error: ‘XVisualInfo’ undeclared (first use in this function) togl.c:1764: error: ‘visinfo’ undeclared (first use in this function) togl.c:1795: error: expected ‘;’ before ‘VisInf’ togl.c:2117: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2118: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2119: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2120: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2121: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:2122: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:2123: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2123: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2123: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:2124: error: ‘Togl’ has no member named ‘EpsMapSize’ togl.c:2187: error: ‘TkWindow’ undeclared (first use in this function) togl.c:2187: error: ‘winPtr’ undeclared (first use in this function) togl.c:2187: error: expected expression before ‘)’ token togl.c:2213: error: ‘Togl’ has no member named ‘VisInfo’ togl.c:2213: error: ‘Togl’ has no member named ‘VisInfo’ togl.c:2214: error: ‘Togl’ has no member named ‘VisInfo’ togl.c:2338: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c:2340: error: ‘MacDrawable’ undeclared (first use in this function) togl.c:2340: error: expected expression before ‘)’ token togl.c:2352: error: ‘VisInf’ undeclared (first use in this function) togl.c:2388: error: ‘Togl’ has no member named ‘EpsMapSize’ togl.c:2389: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2390: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2391: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2392: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2393: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:2394: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c:2395: error: ‘Togl’ has no member named ‘EpsMapSize’ togl.c:2396: error: ‘Togl’ has no member named ‘EpsRedMap’ togl.c:2397: error: ‘Togl’ has no member named ‘EpsGreenMap’ togl.c:2399: error: ‘Togl’ has no member named ‘EpsBlueMap’ togl.c: In function ‘Togl_EventProc’: togl.c:2594: warning: ‘AGLDrawable’ is deprecated togl.c:2596: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c:2610: warning: ‘aglSetDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:313) togl.c: In function ‘Togl_LoadBitmapFont’: togl.c:3143: warning: ‘aglUseFont’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:374) togl.c: In function ‘Togl_DumpToEpsFile’: togl.c:3750: error: ‘Togl’ has no member named ‘EpsMapSize’ togl.c:3750: error: ‘Togl’ has
Re: [GRASS-dev] wxnviz on mac osx (grass7.0)
That's the TclTk NVIZ. And it looks like it's configured for the system TclTk (8.5). I tried that a while back when Snow Leopard came out - updated tcltk, 64bits - but had problems compiling, it might have been the same error. You need to install TclTk 8.5 from ActiveState and configure for that. See the Mac compile readme in the source. On Aug 19, 2010, at 6:42 AM, Massimo Di Stefano wrote: Hi, problems to get wx-nviz running on mac osx 10.6.4 building grass7.0 this the log : Finished compilation: Gio 19 Ago 2010 13:31:39 CEST make: *** [default] Error 1 MacBook-Pro-15-di-sasha:grass_trunk sasha$ cd /Users/sasha/gis/grass_trunk/visualization/nviz MacBook-Pro-15-di-sasha:nviz sasha$ make make -C src gcc -g -O2-arch i386 -arch x86_64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -D_FILE_OFFSET_BITS=64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -o OBJ.i386-apple-darwin10.4.0/togl.o -c togl.c In file included from togl.c:53: /usr/include/tkMacOSX.h:31: error: expected declaration specifiers or ‘...’ before ‘TkRegion’ togl.c:54:54: error: tkMacOSXInt.h: No such file or directory togl.c:265: error: expected specifier-qualifier-list before ‘XVisualInfo’ togl.c: In function ‘SetMacBufRect’: ... - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz on mac osx (grass7.0)
On Aug 19, 2010, at 9:36 AM, Massimo Di Stefano wrote: Hi William, right :-) thanks to point me to tcltk i'm on a fresh osx installation .. so i'll rebuild tcltk for both 32+64 bit and reconfigure grass. Just stick with the ActiveState TclTk install. Last I tried to build TclTk 8.5.8 64bit, it didn't work. ActiveState seems to be the 'official' build, and even they don't build 64bit. Tcltk 8.6 is still in beta, and I don't know if 64bit status has improved or if it works in GRASS. but this error wil be not related to the wx-nviz crash, is it right ? i have a wxniz crash on both grass 6.5 and 7.0. Could be something to do with running nviz from inside the GUI. To see if NVIZ itself is OK, just run it from the GRASS terminal. i'll update my tcltk and try again, thanks! Massimo. Il giorno 19/ago/2010, alle ore 16.30, William Kyngesburye ha scritto: That's the TclTk NVIZ. And it looks like it's configured for the system TclTk (8.5). I tried that a while back when Snow Leopard came out - updated tcltk, 64bits - but had problems compiling, it might have been the same error. You need to install TclTk 8.5 from ActiveState and configure for that. See the Mac compile readme in the source. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life. - Marvin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz on mac osx (grass7.0)
Hello Helena, Il giorno 19/ago/2010, alle ore 16.44, Helena Mitasova ha scritto: On Aug 19, 2010, at 10:36 AM, Massimo Di Stefano wrote: Hi William, right :-) thanks to point me to tcltk i'm on a fresh osx installation .. so i'll rebuild tcltk for both 32+64 bit and reconfigure grass. but this error wil be not related to the wx-nviz crash, is it right ? i have a wxniz crash on both grass 6.5 and 7.0. it crashes if you have both raster dem and vector data in gis manager, i tried loading only the raster layer spearfish elevation.dem (without vector loaded in gis manager) after load the raster in the 2d map-display, click on the 3D View give me a wxpython-gui crash to have a log i tried to use : export GRASS_WX_DEBUG=1 GRASS 7.0.svn (spearfish60):~ export GRASS_WX_DEBUG=1 [1]+ Doneg.gui wxpython GRASS 7.0.svn (spearfish60):~ g.gui wxpython [1] 22828 GRASS 7.0.svn (spearfish60):~ GUI D1/1: GMFrame.NewDisplay(): idx=0 GUI D1/1: gcmd.RunCommand(): g.proj -p GUI D1/1: gcmd.RunCommand(): g.region -ugpc GUI D1/1: gcmd.RunCommand(): g.mapsets --q -p fs=newline GUI D1/1: gcmd.RunCommand(): d.rast --q map=elevation@permanent GUI D1/1: gcmd.RunCommand(): g.pnmcomp opacity=1.0 mask=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp7oA4qm.pgm height=515 width=768 background=255:255:255:255 input=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp7oA4qm.ppm output=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp8Lfnkp.ppm GUI D1/1: gcmd.RunCommand(): d.rast --q map=elevation@permanent GUI D1/1: gcmd.RunCommand(): g.pnmcomp opacity=1.0 mask=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp7oA4qm.pgm height=515 width=768 background=255:255:255:255 input=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp7oA4qm.ppm output=/var/folders/ve/veXy9T8eF2mFKQhl31BlvTI/-Tmp-/tmp8Lfnkp.ppm it is still under development - see the wiki page. i know, my mail is just to report what i have here, i hope a log will help to debug the problems. My attempt is to help to debug, building grass several times at week, i usually report a problem if exists tcltk nviz is not supposed to be supported in grass7 i know, all tcltk stuff is dropped from grass7, unlucky i'm just a power-user and i'm not able to fix things i'm on osx i'will be happy to provide you more logs and tests if needed, to guve us a little help. thanks All, for you powerfull grass-work! Massimo. Helena i'll update my tcltk and try again, thanks! Massimo. Il giorno 19/ago/2010, alle ore 16.30, William Kyngesburye ha scritto: That's the TclTk NVIZ. And it looks like it's configured for the system TclTk (8.5). I tried that a while back when Snow Leopard came out - updated tcltk, 64bits - but had problems compiling, it might have been the same error. You need to install TclTk 8.5 from ActiveState and configure for that. See the Mac compile readme in the source. On Aug 19, 2010, at 6:42 AM, Massimo Di Stefano wrote: Hi, problems to get wx-nviz running on mac osx 10.6.4 building grass7.0 this the log : Finished compilation: Gio 19 Ago 2010 13:31:39 CEST make: *** [default] Error 1 MacBook-Pro-15-di-sasha:grass_trunk sasha$ cd /Users/sasha/gis/grass_trunk/visualization/nviz MacBook-Pro-15-di-sasha:nviz sasha$ make make -C src gcc -g -O2-arch i386 -arch x86_64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -D_FILE_OFFSET_BITS=64 -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/UnixImageIO.framework/unix/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/Library/Frameworks/GEOS.framework/Versions/3/unix/include -DPACKAGE=\grassmods\ -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -I/Users/sasha/gis/grass_trunk/dist.i386-apple-darwin10.4.0/include -o OBJ.i386-apple-darwin10.4.0/togl.o -c togl.c In file included from togl.c:53: /usr/include/tkMacOSX.h:31: error: expected declaration specifiers or ‘...’ before ‘TkRegion’ togl.c:54:54: error: tkMacOSXInt.h: No such file or directory togl.c:265: error: expected specifier-qualifier-list before ‘XVisualInfo’ togl.c: In function ‘SetMacBufRect’: ... - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org
Re: [GRASS-dev] wxnviz disabled in GRASS 6.5?
On Thu, Jul 22, 2010 at 11:14 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2010/7/22 Michael Barton michael.bar...@asu.edu: I just compiled GRASS 6.5 updated from the SVN. When I started it, I got the following message: WARNING: Nviz extension (3D view mode) disabled. Reason: No module named ogsf I can launch wxnviz but it won't display anything. It also trashes the GUI. Is this still a backport issue? wxNviz is still waiting for ctypes backport from trunk. I hope it will be fixed very soon. Hi all, I'm starting looking at the backport now. Suggestions - especially on makefiles - are most welcome! anne -- http://gis.fem-environment.eu/anne-ghisla/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz and wxdigit problems
I just updated from trunk and tried GRASS 7 and am getting some ugly errors.
On launching a lot of garbage is being dumped to the terminal--Python
dictionaries for wxnviz and wxdigit (e.g., modeler data). This output also is
dumped to the terminal and console when any command is run.
Also, when I try wxnviz it does not work at all.
Here are some of the errors I get...
Running a command:
===
(Sat Jul 10 07:36:21 2010)
r.info map=geol...@permanent
{'profile': {'raster2': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 255, 0,
255)}, 'raster0': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (0, 0, 255, 255)},
'raster1': {'pstyle': 'solid', 'pwidth': 1, 'pcolor': (255, 0, 0, 255)},
'x-axis': {'max': 0, 'type': 'auto', 'log': False, 'min': 0}, 'y-axis': {'max':
0, 'type': 'auto', 'log': False, 'min': 0}, 'grid': {'color': (200, 200, 200,
255), 'enabled': True}, 'marker': {'color': (0, 0, 0, 255), 'fill':
'transparent', 'type': 'triangle', 'legend': u'Segment break', 'size': 2},
'font': {'axisSize': 11, 'legendSize': 10, 'titleSize': 12}, 'legend':
{'enabled': True}}, 'georect': {'symbol': {'color': (0, 0, 255, 255), 'width':
2}}, 'cmd': {'showType': {'point': {'enabled': True}, 'area': {'enabled':
True}, 'face': {'enabled': True}, 'centroid': {'enabled': True}, 'line':
{'enabled': True}, 'boundary': {'enabled': True}}, 'rasterColorTable':
{'selection': 'rainbow', 'enabled': False}, 'verbosity': {'selection':
'grassenv'}, 'addNewLayer': {'enabled': True}, 'rasterOpaque': {'enabled':
False}, 'closeDlg': {'enabled': False}, 'overwrite': {'enabled': False}},
'projection': {'statusbar': {'epsg': '', 'proj4': '', 'projFile':
'/Library/Frameworks/PROJ.framework/Resources/proj/epsg'}, 'format': {'ll':
'DMS', 'precision': 2}}, 'display': {'outputfont': {'type': 'Courier New',
'size': '10'}, 'statusbarMode': {'selection': 0}, 'autoZooming': {'enabled':
False}, 'driver': {'type': 'cairo'}, 'autoRendering': {'enabled': True},
'bgcolor': {'color': (255, 255, 255, 255)}, 'compResolution': {'enabled':
False}, 'font': {'type': '', 'encoding': 'ISO-8859-1'}}, 'nviz': {'light':
{'color': (255, 255, 255, 255), 'bright': 80, 'pos': {'y': 0.68005,
'x': 0.68005, 'z': 80}, 'ambient': 20}, 'fringe': {'color': (128,
128, 128, 255), 'elev': 55}, 'surface': {'shine': {'map': False, 'value':
60.0}, 'color': {'map': True, 'value': (0, 0, 0, 255)}, 'draw': {'res-coarse':
9, 'style': 1, 'wire-color': (136, 136, 136, 255), 'mode': 1, 'shading': 1,
'res-fine': 6}, 'position': {'y': 0, 'x': 0, 'z': 0}}, 'volume': {'color':
{'map': True, 'value': (0, 0, 0, 255)}, 'shine': {'map': False, 'value': 60.0},
'draw': {'shading': 1, 'resolution': 3, 'mode': 0}}, 'vector': {'points':
{'show': False, 'color': (0, 0, 255, 255), 'height': 0, 'width': 2, 'marker':
2, 'size': 100}, 'lines': {'color': (0, 0, 255, 255), 'width': 2, 'show':
False, 'flat': False, 'height': 0}}, 'view': {'persp': {'step': 5, 'value':
20}, 'pos': {'y': 0.16, 'x': 0.83997}, 'height': {'step': 100},
'twist': {'step': 5, 'value': 0}, 'background': {'color': (255, 255, 255,
255)}, 'z-exag': {'step': 1}}}, 'atm': {'leftDbClick': {'selection': 1},
'highlight': {'color': (255, 255, 0, 255), 'width': 2}, 'askOnDeleteRec':
{'enabled': True}, 'keycolumn': {'value': 'cat'}, 'encoding': {'value': ''}},
'general': {'defWindowPos': {'dim': '', 'enabled': False}, 'elementListExpand':
{'selection': 0}}, 'manager': {'askOnQuit': {'enabled': True},
'askOnRemoveLayer': {'enabled': True}, 'changeOpacityLevel': {'enabled':
False}}, 'vdigit': {'category': {'value': 1}, 'layer': {'value': 1},
'queryLength': {'than-selection': 0, 'thresh': 0}, 'breakLines': {'enabled':
False}, 'selectThresh': {'units': 'screen pixels', 'value': 10},
'snapToVertex': {'enabled': False}, 'selectType': {'line': {'enabled': True},
'centroid': {'enabled': True}, 'boundary': {'enabled': True}, 'point':
{'enabled': True}}, 'snapping': {'units': 'screen pixels', 'value': 10},
'delRecord': {'enabled': True}, 'addRecord': {'enabled': True}, 'selectInside':
{'enabled': False}, 'categoryMode': {'selection': 0}, 'saveOnExit': {'enabled':
False}, 'query': {'box': True, 'selection': 0}, 'addCentroid': {'enabled':
False}, 'lineWidth': {'units': 'screen pixels', 'value': 2}, 'checkForDupl':
{'enabled': False}, 'symbol': {'highlightDupl': {'color': (255, 72, 0, 255),
'enabled': None}, 'boundaryOne': {'color': (0, 255, 0, 255), 'enabled': True},
'direction': {'color': (255, 0, 0, 255), 'enabled': False}, 'point': {'color':
(0, 0, 0, 255), 'enabled': True}, 'area': {'color': (217, 255, 217, 255),
'enabled': False}, 'vertex': {'color': (255, 20, 147, 255), 'enabled': False},
'boundaryNo': {'color': (126, 126, 126, 255), 'enabled': True}, 'highlight':
{'color': (255, 255, 0, 255), 'enabled': None}, 'centroidOut':
[GRASS-dev] wxnviz not compiling in GRASS 6.5 svn
I just updated from the CVS, did a make distclean, and compiled. wxnviz failed to compile with the error 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: www.public.asu.edu/~cmbarton, http://csdc.asu.edu == compile error = Errors in: /Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz -- In case of errors please change into the directory with error and run 'make'. If you get multiple errors, you need to deal with them in the order they appear in the error log. If you get an error building a library, you will also get errors from anything which uses the library. -- Finished compilation: Fri Jun 25 12:18:45 MST 2010 make: *** [default] Error 1 cmb-MBP:grass65_dev cmbarton$ cd /Users/cmbarton/grass_dev/grass65_dev/gui/wxpython/nviz cmb-MBP:nviz cmbarton$ make python setup.py build_ext --swig=/usr/bin/swig --swig-opts=-c++ --build-lib=OBJ.i386-apple-darwin10.4.0 --build-temp=OBJ.i386-apple-darwin10.4.0 running build_ext building '_grass6_wxnviz' extension swigging grass6_wxnviz.i to grass6_wxnviz_wrap.cpp /usr/bin/swig -python -c++ -o grass6_wxnviz_wrap.cpp grass6_wxnviz.i gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -DPACKAGE=grasslibs -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ -I/Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include -I/Library/Frameworks/GDAL.framework/Versions/1.7/Headers -I/usr/local/lib/wxPython-unicode-2.8.10.1/lib/wx/include/mac-unicode-debug-2.8 -I/usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8 -I/System/Library/Frameworks/OpenGL.framework/Headers -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c change_view.cpp -o OBJ.i386-apple-darwin10.4.0/change_view.o cc1plus: warning: command line option -Wstrict-prototypes is valid for C/ObjC but not for C++ In file included from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4, from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60, from nviz.h:26, from change_view.cpp:15: /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) change_view.cpp: In member function ‘std::vectordouble, std::allocatordouble Nviz::SetViewDefault()’: change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument ‘1’ to ‘int Nviz_get_exag_height(double*, double*, double*)’ change_view.cpp: In member function ‘int Nviz::SetView(float, float, float, float, float)’: change_view.cpp:81: error: cannot convert ‘nv_data*’ to ‘double’ for argument ‘1’ to ‘int Nviz_set_viewpoint_height(double)’ change_view.cpp:83: error: cannot convert ‘nv_data*’ to ‘double’ for argument ‘1’ to ‘int Nviz_set_viewpoint_position(double, double)’ change_view.cpp:85: error: invalid conversion from ‘nv_data*’ to ‘int’ /Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:134: error: too many arguments to function ‘int Nviz_set_viewpoint_twist(int)’ change_view.cpp:85: error: at this point in file change_view.cpp:87: error: invalid conversion from ‘nv_data*’ to ‘int’ /Users/cmbarton/grass_dev/grass65_dev/dist.i386-apple-darwin10.4.0/include/grass/nviz.h:133: error: too many arguments to function ‘int Nviz_set_viewpoint_persp(int)’ change_view.cpp:87: error: at this point in file cc1plus: warning: command line option -Wstrict-prototypes is valid for C/ObjC but not for C++ In file included from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/glcanvas.h:4, from /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/glcanvas.h:60, from nviz.h:26, from change_view.cpp:15: /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:49: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) /usr/local/lib/wxPython-unicode-2.8.10.1/include/wx-2.8/wx/mac/carbon/glcanvas.h:53: warning: ‘AGLDrawable’ is deprecated (declared at /System/Library/Frameworks/AGL.framework/Headers/agl.h:48) change_view.cpp: In member function ‘std::vectordouble, std::allocatordouble Nviz::SetViewDefault()’: change_view.cpp:56: error: cannot convert ‘float*’ to ‘double*’ for argument ‘1’ to ‘int
Re: [GRASS-dev] wxnviz not compiling in GRASS 6.5 svn
Hi, 2010/6/25 Barton Michael michael.bar...@asu.edu: I just updated from the CVS, did a make distclean, and compiled. wxnviz failed to compile with the error below. wxNviz C++ component has been replaced in trunk by wxnviz.py. It will be also done in devbr6 when ctypes will be backported. Please use till this time trunk. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxnviz
I am trying to get myself up to date on grass7, especially look at the wxnviz but although I did make distclean and updated grass trunk grass7_wxnviz is not found - am I perhaps missing something in my configure (see below)? thank you Helena P.S. Thanks for nviz_cmd - it is a very helpful addition and can provide capabilities for dynamic surfaces which were lost when nviz tcltk was modified. CFLAGS=-g -Wall ./configure \ --prefix=/local/home/helena/grasssvn \ --with-cxx \ --enable-64bit --with-libs=/usr/lib64 --enable-largefile --enable-shared \ --with-bindir=/local/home/helena/grasssvn \ --with-gdal=/local/home/helena/gsgdal/bin/gdal-config \ --with-gdal-includes=/local/home/helena/gsgdal/include \ --with-gdal-libs=/local/home/helena/gsgdal/lib \ --with-proj=yes \ --with-proj-includes=/local/home/helena/gproj/include \ --with-proj-libs=/local/home/helena/gproj/lib \ --with-proj-share=/local/home/helena/gproj/share/proj \ --with-fftw \ --with-motif \ --with-freetype \ --with-freetype-includes=/usr/include/freetype2 \ --with-sqlite \ --with-python Started compilation: Tue Jan 6 15:49:13 EST 2009 -- Errors in: No errors detected. import grass7_wxnviz as wxnviz ImportError : No module named grass7_wxnviz Traceback (most recent call last): File /local/home/helena/grasssvn/grass-7.0.svn/etc/wxpyth on/gui_modules/toolbars.py, line 250, in OnSelectTool self.mapdisplay.AddToolbar(nviz) File /local/home/helena/grasssvn/grass-7.0.svn/etc/wxpyth on/gui_modules/mapdisp.py, line 2717, in AddToolbar import nviz File /local/home/helena/grasssvn/grass-7.0.svn/etc/wxpyth on/gui_modules/nviz.py, line 42, in ? import nviz_mapdisp File /local/home/helena/grasssvn/grass-7.0.svn/etc/wxpyth on/gui_modules/nviz_mapdisp.py, line 40, in ? import grass7_wxnviz as wxnviz ImportError : No module named grass7_wxnviz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxnviz
Helena Mitasova wrote: I am trying to get myself up to date on grass7, especially look at the wxnviz but although I did make distclean and updated grass trunk grass7_wxnviz is not found - am I perhaps missing something in my configure (see below)? You need --with-wxwidgets for the vdigit and nviz add-ons to the wx GUI, also for the xganim replacement. Also, --with-motif no longer exists. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
