#128: NVIZ fails to load vector points without other map
---------------------+------------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Keywords: tcl |
---------------------+------------------------------------------------------
I hoped to load a 2D or a 3D points map into NVIZ (Lidar points). But it
crashes:
nviz point=lidar1map3d
WARNING: Adapted sites library used for vector points (module should be
updated to GRASS 6 vector library).
Site dim: 3
Sites file lidar1map3d loaded.
Error in startup script: can't use non-numeric floating-point value as
operand of "*"
while executing
"expr int($curr * 1)"
(procedure "Nv_mkFloatScale" line 16)
invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height
1"
(procedure "mk_hgt_slider" line 12)
invoked from within
"mk_hgt_slider $BASE.midf"
(procedure "mkmainPanel" line 143)
invoked from within
"mk$name\Panel $path"
invoked from within
"if [catch {set Nv_($path)}] {
set file panel_$name.tcl
set Nv_($path) [mk$name\Panel $path]
}"
(procedure "Nv_force_panel" line 8)
invoked from within
"Nv_force_panel main"
(procedure "Nv_makeGUI" line 183)
invoked from within
"Nv_makeGUI .top"
(file "/home/neteler/grass63/dist.x86_64-unknown-linux-
gnu/etc/nviz2.2/scripts/nviz2.2_script" line 1046)
}}}
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by hamish):
FWIW, I've been able to plot a vector map in NVIZ which had 1 million
faces*, it took some time to render but it worked ok.
* NYC 3D buildings dataset
(but points are treated differently than lines and faces in NVIZ)
see also bug #49: NVIZ displays points (sites) always as thematic
In the past I was able to plot 3D points, but created a new constant
surface (so no mapname) from the raster panel and set transparency for it
to 100%; a trick I'm sure you know. screenshot: http://grass.osgeo.org/wiki/Help_with_3D#Vector_3D_point_data
does it work for you with fewer points or does it work with a surface
(constant or raster map)? [what do you mean by "without other map"?]
{{{
Error in startup script: can't use non-numeric floating-point value as
operand of "*"
while executing
"expr int($curr * 1)"
(procedure "Nv_mkFloatScale" line 16)
invoked from within
"Nv_mkFloatScale .....
}}}
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by hamish):
Markus:
> The problem is in "widgets.tcl", line 328:
trac tip # 1: append #L328 to the end of the URL to automatically go to
that line. In the source browser you can click on the line number on the
left to get that.
trac tip # 2: (perhaps less useful) link to a source file with
source:grass/trunk/visualization/nviz/scripts/widgets.tcl#L328
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by neteler):
I get:
{{{
nviz point=lidar1map3d
Vector file lidar1map3d loaded with 38008 points.
...
curr = 1.0
curr = 1.0
curr = nan
Error in startup script: can't use non-numeric floating-point value as
operand of "*"
while executing
"expr int($curr * 1)"
(procedure "Nv_mkFloatScale" line 17)
...
}}}
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by neteler):
Unfortunately I don't know how to debug tcl. but you can easily replicate
it with Spearfish:
{{{
GRASS 6.3.svn (spearfish60):~ > nviz point=archsites
Vector file archsites loaded with 25 points.
curr = 1.0
curr = 1.0
curr = nan
Error in startup script: can't use non-numeric floating-point value as
operand of "*"
while executing
"expr int($curr * 1)"
(procedure "Nv_mkFloatScale" line 17)
invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height
1"
...
}}}
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by hamish):
In scripts/main_panel.tcl just use puts to see what those variables are:
puts "$foo"
And the same with printf() in src/exag.c.
> but you can easily replicate it with Spearfish
('g.region' -d first)
for me, nviz loads that ok. But I don't see any points, just a horizontal
line when I move the puck: zegag is "-0.0". If I change it to 1.0 I get:
{{{
divide by zero
divide by zero
while executing
"expr $val/floor($val/$res)"
(procedure "Nv_floatscaleCallback" line 49)
invoked from within
"Nv_floatscaleCallback .middle.panelarea.panels.main.midf.zexag e 0
update_exag"
("uplevel" body line 2)
invoked from within
"uplevel \#0 $cmd"
(procedure "Entry::invoke" line 3)
invoked from within
"Entry::invoke .middle.panelarea.panels.main.midf.zexag.f.entry"
(command bound to event)
}}}
#128: NVIZ fails to load vector points without other map
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: nviz
----------------------+-----------------------------------------------------
Comment (by hamish):
{{{
g.region -d
nviz points=archsites
# change z-exag from -0.0 to 1.0
divide by zero
while executing
"expr $val/floor($val/$res)"
(procedure "Nv_floatscaleCallback" line 49)
}}}
AFAICT this is because the value $res is set from is used uninitiated.
"$res" there is -0.0, set a few lines above with:
set res [lindex [$S.scale configure -resolution] 4]
if there is a raster (or vol?) surface given from the command line it
calcs $res ok. If not it doesn't. Even if you add in a new raster surface
after starting with "nviz points=" it doesn't set $res and then gets
quickly stuck in some infinite loop.
So how does $res get set for raster maps? If there is no raster map can a
starting value be derived from the current region settings?
This bug still is NOT fixed. Reproduceable with recent 6.4 release branch.
Michael: You are using wrong steps to reproduce this issue. Please use
following steps:
{{{
v.random -z output=point3d n=100 zmin=1000 zmax=2000
nviz points=point3d
Vector map <point3d@vectdel> loaded (100 points)
Failed to initialize TTM buffer manager. Falling back to classic.
Error in startup script: integer value too large to represent
while executing
"expr int($curr * 1)"
(procedure "Nv_mkFloatScale" line 16)
invoked from within
"Nv_mkFloatScale $Nv_(HEIGHT_SLIDER) v height $max $min $val update_height
1"
(procedure "mk_hgt_slider" line 12)
invoked from within
"mk_hgt_slider $BASE.midf"
(procedure "mkmainPanel" line 144)
invoked from within
"mk$name\Panel $path"
invoked from within
"if [catch {set Nv_($path)}] {
set file panel_$name.tcl
set Nv_($path) [mk$name\Panel $path]
}"
(procedure "Nv_force_panel" line 8)
invoked from within
"Nv_force_panel main"
(procedure "Nv_makeGUI" line 194)
invoked from within
"Nv_makeGUI $Nv_(AREA)"
(file "/home/marisn/soft/grass64_release/dist.i686-pc-linux-
gnu/etc/nviz2.2/scripts/nviz2.2_script" line 1052)
}}}
This bug still is NOT fixed. Reproduceable with recent 6.4 release branch.
Michael: You are using wrong steps to reproduce this issue. Please use
following steps:
{{{
v.random -z output=point3d n=100 zmin=1000 zmax=2000
nviz points=point3d
I'm not sure that this is supposed to work. Actually, I was surprised that I could display 3D points without a raster surface using the nviz -q method. Note that the parameter descriptions call both vector and point files as "overlay" maps. That is, it is assumed that they will overlay a surface.
Parameters:
elevation Name of raster map(s) for Elevation
color Name of raster map(s) for Color
vector Name of vector lines/areas overlay map(s)
points Name of vector points overlay file(s)
volume Name of existing 3d raster map
path Set alternative panel path
script Execute script file at startup
state Load previously saved state file
Fix r35144 is just nonportable hack. Still when this place is fixed, nviz
will fail in other places. I have created patches which would fix starting
nviz without raster base map by taking into accound vector 3D extent,
still they need a review (as nviz and ogsf are hairy). IMHO it's safe to
fix this issue in GRASS 7, still I have no idea if it's right thing to fix
in GRASS 6.4, as it changes one of (internal) OGSF functions.
probably that will break lat/lon where x,y units do not match z units.
Try not to make assumptions about what the data is or contains, it is not
necessarily describing earth in familiar units. (think raster maps
containing chemical concentrations etc. made into a surface by v.surf.rst)
Hamish
ps- it is much easier to review if cosmetic (whitespace) changes are kept
to separate patches from bugfixes. signal to noise ratios and all that.
thanks
Replying to [comment:16 hamish]:
> {{{
> if (exag < 0.1)
> exag = 1.0;
> }}}
You are right. It needs to be changed to GRASS_EPSILON test, as previous
code read (exag == 0.0) which isn't the best idea for float comparison.
Still IMHO some code might break if exag is 0 or less.
> ps- it is much easier to review if cosmetic (whitespace) changes are
kept to separate patches from bugfixes. signal to noise ratios and all
that. thanks
I allways run grass_indent.sh after codding FTW. I will prepeare new
patches with ignored whitespace changes (thouse where prepeared in 3 AM).