[GRASS5] The status of 5.0

[Markus Neteler]

On Thu, Mar 21, 2002 at 10:01:36PM -0600, Helena wrote:
> > On the bugtracker:
> > There are many bugs in there. We need people to
> > evalutate them, reproduce them, fix or delay them.
> 
> I tried to go through the bug tracker and while there are some real bugs
> there only very few seem to be release critical. Most of them seem more
> like lack of capabilities (974,975,973,914, part of 912, ..... or
> annoyancies which have a way around it (e.g. my #970,)
>
> So it would be really useful  if release critical bugs could have
> their own priority, I have identified maybe 2-3

Helena, I'm not sure what you mean with "release critical bugs could have
their own priority" - you can, after logging into RT, adjust the
priority after clicking on a bug.
 
> Some problems listed just need better explanation in the
> documentation/instructions
> I am looking into INSTALL and small modifications may help -
> e.g. there is a sentence ....some modules won't be compiled" right at the
> beginning
> of the document.Adding "(for example PostgresSQL or fftw, see section on
> CONFIGURE OPTIONS)"
> may help reduce number of people complaining about Postgres giving errors
> because most people do not read it far enough to learn about it.
> (everybody here who has compiled GRASS was puzzled by Postgres error as many
> people do not even know what it is)

Good suggestion - have updated INSTALL and cp'ed to web as well.

[...]
> -------------------------------------------------------------------------
> concrete comments, suggestions for removals from the list
> 
> 905
> really is not a bug, to me putting a space between + 18 actually makes sense
Mhhh, I don't actually like that when *accidentally* entering +18 (without
blank) deletes my entire SEARCH_PATH. Then I have to go and reconstruct it,
just because this blank is needed.

> what do we do with "bugs" like this - keep them there with low priority
> (there is plenty of them there) or vote whether they should be removed?

You can change the area to "wish" after clicking on "Area" on top of the
bug report.


> 912 r.mapcalc
> was anybody able to reproduce that bug?
>     I tried all kinds of combinations on various types of files
>     and did not get "no result" problem. Markus, wasn't there something wrong
>     with your file?

Well, maybe, but it is rather difficult to make things worse with raster
maps :-) If not reproducable, let's close it. I'll write a new report
if needed.
Glynn, am I right that your r.mapcalc3 will replace r.mapcalc near future?

> Both of the following "problems" are issues related to the question whether
> anybody should use r.mapcalc without reading the man page and how much of
> instructions should be put into the messages given by the program -
> Markus are you suggesting that if r.mapcalc finds that it has a map with
> NULLs
> it should give a warning? Similarly should there be a warning for division of
> two INT maps?
> (that should reduce number of confused people, but on the other hand people
> should really read manual before using r.mapcalc)

as we all know nobody reads manuals (carefully). So I suggest to output a
warning in both cases. Especially the NULL "problem" is less obvious than
the division of two INT maps == INT. In more complex formula you don't
easily realize sometimes why the result is wrong (if you ever see it) and
that you should use isnull()

> - r.mapcalc *silently* does not operate on NULL values (there should be
>       a warning)
> - does not print a message about the file type (INT,FCELL) when doing
>       a calculation (e.g. when dividing two INT maps, the result is INT.
>       but many users may not realize this and don't know that they have to
>       multiply with 1.0 to receive a FCELL)
> 
> 913 looks like the users problem

I have closed this one - no response.

> 897 r.slope.aspect is indeed a GRASS4* story when 0 was no-data and rasters
> were mostly classes.
> Labeling 360 classes as it is there now does not really make much sense so to
> make it meaningful it would require to create maybe 12 ranges and label those
> or
> skip labeling altogether. But this is more like a wish than a critical bug.
> r.param.scale is probably similar case

.. changed to "wish".
 
> 895 - more likely a wish? lack of capability?

.. changed to "wish". Will probably need a Tcl/TK hack.

> 889 same as 836 - nvizOsx has a note that it may be closed but it is still
> there

I have closed this one - no response.

> 888 is not a bug - should be removed
I have closed this one - no response.

> 878 not a bug
I have closed this one - no response.
> 
> 877 not abug

I have closed this one - no response.

> 873 should be given low priority

It has "30" - should be fine.
 
> 870 seems to be resolved

I have closed this one - probably really a data problem.

> 868 not release critical?

commented v.out.mif in src/CMD/lists/GRASS, obviously not working

If I am wrong, someone may reactivate it.
closed the bug report.

> 858 does Radim's answer solve the problem at vector support GRASS5.0 level?
> or is this release critical Markus?

after discussion with Radim (I can see him here :-) I think it is a data 
problem (import of non-topological data). v.support should be mostly fine.

> 855 Any news about v.trim? Release critical?

Some guest without name wrote"
   I am working on a fix of v.trim, it does a pretty good job already but it 
   doesn't care much yet about the attributes! More soon."

Who was that?? so far v.trim is unchanged in CVS.

> 853 sounds like release critical?

Yes, I think so. When digitizing areas in v.digit and using the
text label function, the area labeling is done as if the area
were a line. That causes problems later.
Needs to be verified by someone else.

> 756 can be removed - I was never able to reproduce it and never got
> confirmation about the problem from the submitter

I have closed this one - as no response.

> 256 s.surf.krig - kriging is much better served by linking with geostats
> packages as you need lots of additional tools to make it really useful -
> GSTATS and R-stats would be much better for that. Unless somebody wants to
> undertake major geostatistics developments fully integrated with GRASS
> (inclding s.sv and other tools) I suggest retiring it and rather work on
> improvements and education for R-stats bridge and GSTATS link

I have closed this one. (btw: gstat, not gstats in case somewhat wants to
google for it)

> 251 - isn't this listed as an issue for GRASS5.1 milestone?
Yes, closed.

Thanks for looking into so may reports.

 Markus