Dear developers,
here the latest BUGS file with a suggestion for release-critical
bugs. If possible, please tell me which bug(fix) you can take over.
Some names are already in.
Which bugs are missing, which are [not] critical?
Thanks for reading
Markus
----------------------------------------------------------------
Known bugs in GRASS 5
$Id: BUGS,v 1.35 2000/10/18 13:30:13 markus Exp $
[In sync with GRASS 5 beta CVS version]
Maintained by
Markus Neteler
neteler@geog.uni-hannover.de
Please send a note if detecting an unknown bug.
Bugfixes are very welcome!
Bug report page:
http://www.geog.uni-hannover.de/grass/bugtracking/bugreport.html
For the forthcoming GRASS 5 stable release there are some bugs
being release-critical. They are indicated [RC].
----------- drivers ---------------------------------------------
[RC] CELL-Driver: colors are not correct
Comment from Carl Anderson <candrsn@mindspring.com>
Tracking of the "bug" will have to start in
src/display/d.rast/cmd/display.c
Since GRASS4 did the colors right, using both GRASS4 and GRASS5
drivers, I suspect one of the Libraries and not the XDRIVER.
look at D_set_colors ().
(being worked on by ?)
----------- libraries ---------------------------------------------
G3D libraries bug:
Markus Neteler wrote:
If I have more than around 60.000 cubes (tiles) (when setting high
resolutions in WIND3) I regularly get this error message:
r3.out.v5d map=3dvol out=3d.v5d
FATAL ERROR: G3d_getDoubleRegion: error in G3d_getTilePtr
r3.out.ascii map=3dvol > 3d.asc
FATAL ERROR: G3d_getDoubleRegion: error in G3d_getTilePtr
Jaro Hofierka wrote:
Markus,
briefly, the problem might be in cache modes. The functions G3d_getValue () should be
used in a cache mode, however, we open maps using non-cache mode:
map = G3d_openCellOld(input, G_find_grid3(input, ""), G3D_DEFAULT_WINDOW,
G3D_TILE_SAME_AS_FILE,
G3D_NO_CACHE);
Please try to change G3D_NO_CACHE parameter to G3D_USE_CACHE_DEFAULT, and
re-compile main.c for r3.out.ascii with G3d_getWindow() and G3d_getValue()
commands or previous version of r3.out.v5d. Currently I have not enough
time to try it.
Jaro
-> needs to be fixed
(being worked on by ?)
----------- modules ---------------------------------------------
[RC] d.his:
- color wrong if input value=0
- added NULL randomly when using "out" for saving
(being worked on by ?)
d.mon: hangs with "-L" option
(would be nice to fix to improve "d.monsize" script
Andreas Lange wrote:
The d.mon -L bug only occurs on Linux, on IRIX
everything is ok. I read the code and experimented with it, but i
couldn't find the problem. This is something for the signal
specialists/system programmers from BSD and SYSV.
(being worked on by ?)
d.param.scale
- lower axis description not readable
- sometimes "floating point exeption", especially in par=geary
(being worked on by ?)
[RC]d.profile: the min/max printed at profile are wrong
sometimes the entire profile wrong
obviously problem with fp/int maps
* displays the correct location and elevation with the "where
am I" selection, but generates a flat line profile for any transect
across my raster elevation maps. The flat line has a consistent value on
the y axes of 17519 and /3963632 at the origin. I recall this module
worked ok for me in early 5b releases, but has failed in this manner in
both 5b7 and 5b8.
(reported by Tom Strang tstrang@trytel.com)
(being worked on by ?)
d.rast.num: some numbers are displayed in wrong (unreadable) color
(being worked on by ?)
[RC]d.rgb: Is there a difference between d.rgb and i.composite?
(being worked on by ?)
[RC]d.siter: try to make it indpendent from wish8.x version (like tcltkgrass)
but startup error occurs now.
(being worked on by ?)
[RC]d.sites.qual: not all the sites are used/displayed
d.sites.qual doesn't work properly: not all the sites
are used/displayed if the number of fields of the input site file is
not constant. Compare with d.sites.
(being worked on by ?)
[RC]d.what.rast
displays its output twice to the tcltkgrass screen and
prints it twice to file when in single selection mode. In command line
mode d.what.rast works fine. I program in c and tcl, so I looked around
a bit at the sources - but don't have the familiarity with the code base
to find an obvious solution.
(reported by Tom Strang tstrang@trytel.com)
(being worked on by ?)
[RC]i.ortho.photo
- if second control point is set by mouse, it is not indicated
immediately in orange color (right window)
- GIS WARNING: Can't write embedded null values for map open for random
access: i.ortho.photo/photo.rectify/write.c needs to be updated.
(being worked on by ?)
i.tape.tm.fast: (Todd Shoemaker, jtshoe@datasync.com)
- Attempting to change the default Title causes a segfault.
(being worked on by ?)
g3.region:
- after defining the 3D-region with g3.createwind (which runs o.k.),
the g3.region does not display the vertical resolution (top-bottom)
correctly. -> rounding error?
-> r3.info is affected as well
(being worked on by ?)
p.map.new:
- p.map.new now works but only with the grass4.2 raster files
With the GRASS5.0 floating point raster files it gives the following
error.
WARNING: [desi] in mapset [PERMANENT] - format field in header file
invalid
WARNING: unable to open raster map [desi] in mapset [PERMANENT]
desi in PERMANENT : can't open raster file
I think it is to do with the new format of GRASS5.0 raster files.
-> 5/2000: still a problem??
(being worked on by ?)
[RC]ps.map:
compiler option -fwritable-strings is required on Linux (only)
some variable implementation needs to be improved.
(being worked on by ?)
[RC]r.binfer
- bug in table.c causing segfault
- probability "1" not accepted
(being worked on by David D Gray)
[RC]r.contour: (reported by D D Gray <ddgray@armadce.demon.co.uk>)
Though it is not a stability problem, I've found that if this module is
run on an elev raster with an active old-style mask, i.e applied with
r.mask, the contour lines which terminate on the mask boundary (but only
these) are duplicated, as if reflected off the mask boundary. The
resulting line is then closed giving a closed loop that is folded in on
itself with a node at one end or in the middle of the line, and no node
at the other. This is most clearly seen when viewed with v.digit. I have
not seen a prior report of this problem though I have looked. My
apologies if this has already been documented. Though I can't look into
this myself at the moment, I have prepared a quick fix in the form of an
awk post-processor which ´cleans' this problem, splitting the loop and
removing the duplicate segment (it also removes ´degenerate' lines ie.
lines of one point which r.contour creates occasionally.) I have added
this as an extension, though I stress it is just a temporary fix.
(script: v.asc.degen)
(being worked on by David D Gray)
[rc]r.flow
bugreport: Issuing the command (-M switch is the problem):
r.flow -M elevin=fill aspin=dir flout=flowout_M dsout=density_M
[...] Writing density file...ERROR: r.flow: cannot write segment file for
density_M
r.flow seems to work OK with no switch and with the -m switch.
(reported by david_finlayson@yahoo.com)
-> floating point exception fix already done, -M to be tested
(being worked on by ?)
r.in.hdf/r.out.hdf (src.garden/grass.hdf)
- needs updating to HDF5.x lib (already there)
(being worked on by ?)
[RC]r.in.png:
seg. faults on Pentium CPU (compare r.binfer)
(being worked on by David D Gray)
[RC]r.in.ppm
seg. fault on Pentium CPU (compare r.binfer)
Memory bug fixed by Alex Shevlakov
(being worked on by David D Gray)
[RC]r.in.tiff/r.out.tiff
- segm. fault (same thing with r.binfer)
(reported by Stephan Holl <Stephan.Holl@stud.uni-hannover.de>)
(being worked on by David D Gray)
[RC]r.los:
r.los seems to work perfectly if the elevation data is UTM. But if the
elevation data is latitude-longitude, like most of my elevation data, the
output map looks like a hollow footprint: mostly "N" for cell values, except
for a few arcs of cells with values like 179 and 180, out where the horizon
might be expected. If indeed these values mark the horizon, why do so few
(if any) cells between these arcs and the observer's cell have non-"N"
values?
I tried a previous Grass version (5.0 beta 6) to see if r.los works with
latitude-longitude-projected elevation data, but the output maps look just
as bad. Sometimes the output map looks like a TV-test-pattern: a really
bizarre pattern of radial lines emanating from the observer towards the
west. Cells in this region have values in the millions or billions (I
forget how many digits). The lines don't converge all the way to the
observer because the radial pattern is cut off along a vertical
(north-south) line. To the east of this vertical line, the cells have
smaller values - typically a few hundred - and form vertical stripes when
when the color map is rescaled to the lower values.
Presumably the TV-test-pattern anomalies plagued only old versions of r.los,
but the hollow footprint anomaly persists in the current version. What am I
doing wrong?
(reported by Pelizzari, Michael <michael.pelizzari@lmco.com>)
(being worked on by ?)
[RC]r.mapcalc
- Values -129 in GRASS raster files are treated as Null
(already fixed for FreeBSD/Linux. Check for other platforms,
further corrections go here: src/libes/gis/null_val.c)
(being worked on by ?)
- r.mapcalc does not like it if the cellvalues are very high for eg.,
initially I put the col=fips which ranges from 1001 to 55141 - it
core dumped ... I guess the limit in r.mapcalc is 32xxx which
is a "huge" limitation
(reported by Anantha Prasad aprasad@fs.fed.us)
(being worked on by ?)
- r.mapcalc/polish: (when compiling)
make[2]: Entering directory
/home/neteler/src5/grass5.0beta/src/raster/r.mapcalc/polish'
rm -f lex.yy.c y.tab.c
rm -f OBJ.i586-linux-elf/main.o
gcc -g -O2 -I/home/neteler/src5/grass5.0beta/src/include -c main.c
mv main.o OBJ.i586-linux-elf/main.o
flex pol.l
yacc pol.y
yacc: 14 shift/reduce conflicts, 17 reduce/reduce conflicts.
(being worked on by Andreas Lange)
[RC]r.neighbors
seems doesn't work with a float number
when use median method. It fails in -0.001 value with 3x3 window.
(reported by Bruno Crippa <bruno@ipmtf4.topo.polimi.it>)
(being worked on by ?)
[RC]r.null:
does not work with reclassified maps
(being worked on by ?)
[RC]r.random:
needs to be updated to GRASS 5
(being worked on by ?)
[RC]r.reclass:
- segm. fault on Pentium CPU (same problem as r.binfer,...)
- does not accept "*" to reclass NULL values
r.resamp.rst:
When processing quite a big DEM file with r.resamp.rst I got the
following message for output file:
WARNING: quantization file [z_50] in mapset [erdep] empty.
Does anybody knows what is going on? I tried to run r.support but no
success. Iseems that r.resamp.rst finished its correctly.
(Reported by Rado Bonk <rado@cosmos.dsc.unomaha.edu>)
(being worked on by ?)
[RC]r.rescale:
r.rescale input=asp1 from=0,180 output=test_north to=1,1
r.rescale does not set cells outside the "from" range to 0 (described in the
help), but to NULL
(reported by timcera@earthlink.net)
(being worked on by ?)
r.surf.contour
(supports currently CELL type only)
(being worked on by ?)
r.stats: some inconsistent results comparing to r.average
*First, I compute the per-class averages:
r.average base=medv cover=test out=borra.me
*Second, I check the result for, i.e., class 23:
d.what.rast map=medv,borra.me
2676500(E) 4409500(N)
medv in user1 (23)S_SUPRAMEDITERRANEAN_ZONE
borra.me in user1, quant (111)
borra.me in user1, actual (110.794075)
*Third, I compute the statistics for each class, but the results are not
the same as given by d.what.rast. For example, for class 23:
r.stats -c in=medv,borra.me
r.stats: 100%
...
23 110.299171-110.744906 6082
...
*While d.what.rast was giving 110.794075. Is this a bug?
Dr. Agustin Lobo, alobo@ija.csic.es
(being worked on by ?)
r3.in.v5d/r3.out.v5d:
src.contrib/GMSL/g3d/src3d/raster/r3.in.v5d/binio.c
src.contrib/GMSL/g3d/src3d/raster/r3.out.v5d/binio.c
-> does not yet contain little/big endian sensivity (currently set only by
compiler flag)
solution: code could be taken from src/libes/ogsf/gsd_img_ppm.c
(being worked on by ?)
r3.mapcalc/polish: (when compiling)
mv main.o OBJ.i586-linux-elf/main.o
flex pol.l
yacc pol.y
yacc: 14 shift/reduce conflicts, 17 reduce/reduce conflicts.
(being worked on by Andreas Lange)
r3.showdspf.openGL: (src.contrib/GMSL/g3d/src3d/raster/r3.showdspf.openGL)
- the dependency to OpenGL and Mesa should be checked automatically
and maybe the sgi-widget should be compiled in statically.
it will not work with standard Mesa RPMS, because the sgi-widgets
are missing. Generally you need to have the Mesa source and compile
the libGLw yourself (which is described in the README.mesa31 in the
source for grass.) [Bernhard]
-> partly done by global configure
-> runs fine with MESA 3.2
(being worked on by ?)
[RC]s.surf.krig
Not working. Needs various bugfixes.
Calls to G_distance() seem to suffer stack corruption. The values
of parameters passed in and out of G_distance() are corrupted.
(being worked on by David D Gray)
v.cutter:
For reducing the volume a rather large vectormap (16.000 polygons) I wrote a
grass5-script which
1. automatically generates a rectangle around the current region (works at
least with tmerc,lat/long,lambert-projection)
2. cuts the original map with v.cutter
3. runs v.spag -i and v.support
This works fine, but only sometimes. I cut country outlines, DEM-contours
(created with r.contour) and a map with soil properties and I noticed that
the size of the region seems to influence v.cutter. If, for example, i cut
parts of the coastline of norway, v.cutter works for a region with a maximum width
of 6 geographic degrees, a wider region produces an empty vector file. The
DEM-contour-map, which seems to contain much more data, can be cut using a
region of any size.
Thus it appears that certain combinations of datafile and cutterfile cause
v.cutter to generate no vectors at all. I don't see any rule as to when it
works an when it doesn't so I think that this might be some bug in
v.cutter.
(reported by Stefan.Neumann@agrar.uni-giessen.de)
(being worked on by ?)
[RC]v.out.shape:
segmentation fault on Pentium II CPUs /Linux
(reported by Stephan.Holl@stud.uni-hannover.de)
(being worked on by David D Gray)
[RC]v.reclass:
The problem with v.reclass seems to stem from an input field for old=new
reclass rule that cannot be more than 7 characters long (i.e. 11250=16 is
eight characters long and will cause v.reclass to return an error). Someone
needs to look at correcting this perhaps.
(being worked on by ?)
[RC]v.to.rast:
Working with a vector file and a region of(11242 rows*13301 cols) the
module is 'killed' at step 13/22.
Module works well with the same data and a smaller region.
My pc conf:pentium3 600 & 128 RAM
(reported by marco <scurra@infinito.it>)
(being worked on by ?)
-----------------------------------------------------------------------
Further discussion/hints:
-----------------------------------------------------------------------
- Comments on updating 4.x vector modules to 5.x vector:
There is a slightly modified category support:
Comment on vector cats from Bill Hughes:
The Categories structure was changed between 4.x and 5.0beta.
The change seems to have moved the *labels element out of the list
structure and replace list.num with the index to **labels. The fix
is to change the SCS/* code to use 'cats->labels[i]' instead of
'cats->list[i].labels' There will be breakage around 'list[i].num'
as well, and probably these can be deleted, or use 'cats->num' instead.
The cats.count is cats.ncats now (see src/include/gis.h).
Already sucessfully updated: v.random,v.extract,v.merge,v.autocorr
updated src.contrib tree as well (10/99, Bill H.)
--------------------------------------------------------------------
Libraries bugs:
src/libes/geom: optri -> used by s.geom, v.geom
I [Bill Hughes] have been working through some errors in
src/libes/geom/optri and I have a tarball of the directory attached below.
This is not done yet, but it needs some expertise from somebody who
understands it. Two references to grAllocate() have only 3 parameters.
I don't understand what it does, so I can't really guess at what
should be passed as the final parameter. I have put in 0 for the
moment to get the compile to work.
(being worked on by Andreas Lange)
src/libes/geom/:
[from Brook] The powerof2 warnings are the result of an unfortunate
collision of names (with different semantics) between NetBSD headers
and Grass. As long as the Grass headers are always included _after_ the
system headers it is ok; it would be safer to rename it to something
else within Grass, though.
-> same warning on Linux/Intel
(being worked on by ?)
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'