[GRASS5] some BUGS/missing features

Andreas Lange Andreas.Lange at Rhein-Main.de
Fri Jan 12 07:10:39 EST 2001

Hi all,

Markus Neteler wrote:
> > r.poly:
> > r.poly respects the actual region settings, while r.line does not.
> > I think that at least for the new vector lib every module should either
> > use the actual region settings or ignore them. Not sure which is better.
> All raster modules are sensitive to the actual region settings. I just
> have fixed r.line (io.c): G_set_window() should have been G_get_window().
> Please try the updated version.

This doesn't work. I think now that if r.poly uses the region settings,
r.line should too. 
The vector modules can not use the current region setting, as this would
require an extra round of cutting and probably affect topology in
unwanted ways. 

> > v.patch:
> > v.patch uses the region info from the first vector map header and
> > ignores the users region settings. As the region info from the map
> > header is not reliable, this should be upgraded in a future vector lib
> > redesign.
> David, Radim?

This is more a long-term wish. No need to implement this with the old
vector lib IMHO.

> > v.to.rast:
> > v.to.rast does ignore some areas when used in a very small region.
> > Something not correctly working. I have to further investigate this. May
> > be some problem with the boundary resolving.
> Thanks in advance!

Will look again now. 

> > d.what.rast:
> > If using d.what.rast slope at PERMANENT in a users mapset (e. g.
> > 'andreas'), it get the error: WARNING: Can't open header file for [slope
> > in andreas], but works otherwise correct. I assume the header is not
> > searched in the correct dir.
> Perhaps similar to s.to.vect bug?
> -> please report in out new RT...
> > v.what/d.what.vect:
> > v.what -i and d.what.vect are very similar and could be merged to one
> > module? Not quite sure here.
> Yes! Same thing with r.what/d.what.rast.
> Or we decide that [rv].what are for script programming and
> d.what.[vect|rast] are for interactive usage. Should get comparable module
> behaviour.
> > r.what/d.what.rast:
> > r.what and d.what.rast are (not really) similar and could be merged to
> > one module?
> see above.

I think now that r.what/v.what should be shell-style and d.* interactive
modules. No need to have the interactive part in the r./v. modules. 
Then the d.* modules could check for display availability. It is
important IMHO that the output of both d and r/v modules is identical. 

Reported to the request tracker.

> > v.cutregion:
> > A module v.cutregion would be very handy to cut a vector map to the
> > actual region. When i import from ascii vector files all vectors get
> > imported, irrespectable if they fall into the current region or the
> > whole GRASS region. This stems from the handling of the ascii header i
> > think. With the new vector lib this could be handled correctly, but as a
> > intermediate fix a module v.cutregion would be very useful.
> I think this is on the way for 5.1 (David, Radim?).

I am aware that there are many improvements on the way. But i have to do
my work right now.
So i need a solution that works. 
I wrote a shell script for creating a vector bounding box for the
current region settings and a second script for cutting the actual
region from this. 
If there is general need for both scripts please tell me.

> > Please tell me if i should feed the above bugs/missing features into the
> > request tracker.
> see above :-)



Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net

If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'

More information about the grass-dev mailing list