[GRASS-dev] d.m/d.gis mysteries..

[Dylan Beaudette]

After following this thread for a while, I would like to throw in a couple 
thoughts.

On Monday 30 October 2006 06:34, Maciej Sieczka wrote:
> Moritz Lennert wrote:
> > Maciej,
> >
> > In no way was what I wrote intended as a personal attack. If this is how
> > it came across, I sincerely apologize.
>
> OK, no problem.
>
> > Up to now you are the only one who has raised this issue as a problem.
> > Maybe this is because you are the only one conscious of it and many
> > people are actually misusing gis.m thinking that they get a precision
> > which they are actually not getting. Maybe it is because those who need
> > such level of precision have the habit of going through g.region. Or
> > maybe it is because those who need it are working on the command line and
> > so don't use gis.m. I don't know the reasons...

Moritz : Although I have not contributed to this discussion until now, this 
bug is something that bothers me as well. In fact, the implications of the 
behavior of d.zoom were not fully clear to me until Maciej pointed them out 
on the list one day. Since most of my work deals with point and raster data, 
strict adherence to the region settings are of the utmost importance. I now 
always check, and sometimes reset, the region with the -a flag to maintain 
meaningful (for me) settings.

Michael: I understand how difficult it can be to implement something that you 
need, especially when you are not a programmer by trade. I am in the same 
boat, and have found myself getting into trouble now and then when I dabble 
into developing my own tools. You have done a tremendous effort on the gis.m 
interface and should be proud. However, Maciej is correct in pointing out 
that there is a bug, and that it needs to be addressed sooner than later. 
Nothing puts people off more than inconsistent, or even worse, inaccurate 
behavior of some product. Not to say that gis.m isn't ready for general use, 
rather this issue really should be tackled with the help of the core 
development team.

> Who raises a given issue is not a criterion. The only criterion is
> wheter the issue is there or not. Since I have started using GRASS I
> have found many bugs, including numerous long-standing, which nobody
> has raised before. Also other folks have found bugs which I was never
> aware of.
> > So, the first question to be asked is: does everyone agree that this is a
> > bug ?
>
> We don't need to vote on this. There is a functionality which doesn't
> do what it designed for, and this results in corrupted region settings.
> This is a bug. I'm not going to debate on whether 1=1 anymore.
>
> > If yes, then I agree completely that this needs to be fixed. But as
> > always developer time is limited...and there are other bugs in GRASS
> > which those who have the skills find more important.
> >
> > The current situation definitely is not easy as we are in a transition
> > phase between gui's with a very important step being gis.m, but at the
> > same time this is already poised to be replaced. This makes the issue
> > more difficult, as Michael has to deal with three different GUIs at the
> > same time, and it is not always clear which of these should be the
> > priority.
> >
> > I am willing to help you try to identify whether there are possible
> > solutions to the issue in gis.m,
>
> Thanks for the offer, but you can only help someone able to fix the bug.
>
> > but definitely not before next week and
> > as Markus wants to release 6.2 tomorrow, I am afraid it will have to wait
> > for a bug fix release.
>
> I didn't even try to say that the 6.2 release should be hold off till
> the bug is fixed, because I know this is not realistic. There are many
> bugs not fixed and this doens't make me trying to hold of the release
> either. Since I remember, GRASS has been always released with known
> bugs not fixed, and GRASS developers convinced me that it is inevitable
> - too little people working on the project compared to size of the
> codebase. Since I can't fix any bug myself I don't even dare to tell
> others what to do anymore. But this doesn't mean I should not inform
> others about bugs I found, wishing that soemone can fix it. I'm not
> going to pretend there is no bug.
>
> There have been many bugs squashed in gis.m recently by Michael.
> Encouraged by that, until this another bug has cropped out, I've been
> thinking gis.m will really become stable soon and d.m can dropped
> altogether. Now that this bug is known and there is no cure for it,
> until the bug is fixed, d.m should remain at least as an alternative.
> I, personally, would even prefer d.m as the default GUI back, due to
> this particular bug - the high risk of corrupted region settings is too
> serious for me to bear it. But I'm not going to insist or argue on
> that, I'll settle for what others decide for. At least don't remove d.m
> until the bug is fixed.
>
> Maciek
>

I agree with Maciej on these points, and strongly feel that d.m should remain 
in the 6.x releases. Although I mainly use the d.* commands directly, I 
prefer the simplicity of d.m, and would like to have it as an alternative to 
the gis.m for the time being.

Cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341