[GRASS5] some BUGS/missing features

[Markus Neteler]

On Fri, Jan 12, 2001 at 01:10:39PM +0100, Andreas Lange wrote:
> 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. 
Here r.line works perfectly now on Linux with any region setting.
I guess you missed to run "make install" or so?

> 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. 
Yes. Radim and David already have some ideas for this for 5.1.
 
> > > 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.
I agree - that's for 5.1.

[...]
> > > 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. 
Definitly! Your proposal sounds good to me.
> 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.
At least I would like to have such a script. Intersecting and cutting is not
at it's best at time...
 
Markus

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