[GRASS5] some BUGS/missing features

[Andreas_Lange1]

Hi,

i wish everyone here a happy new year 2001!

While doing some work with GRASS5.0(beta11/CVS) i discovered some minor
BUGS and some missing features.

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.

s.buffer:
s.buffer is missing, but html-page is still there. s.buffer is IMHO no
longer needed, this is the same than v.circle?

v.circle:
v.circle does echo an error with spearfish - bugsites data, but seems to
work ok. It says something about wrong attributes?

s.to.vect:
s.to.vect does not find bugsites@PERMANENT when in users mapset (e. g.
'andreas'), but does not flag this error when in interactive mode. The
module trys always to find the file in the actual mapset, not in the
@PERMANENT mapset. Should be a simple fix.

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.

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.

d.save:
d.save does not work with text output (d.text), text is not saved.

d.redraw (script):
d.redraw does not work with multiple frames and does not work if d.text
is used (see d.save error).

d.what.rast:
If using d.what.rast slope@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.

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.

r.what/d.what.rast:
r.what and d.what.rast are (not really) similar and could be merged to
one module?

gnuplot:
v.to.gnuplot is missing, instead of html-page which is still there.
g.gnuplot is missing, instead of html-page, which is still there. (can't
say if gnuplot inside GRASS is really useful).
The old g.gnuplot works by drawing in a GRASS monitor, which could be
useful for creating histograms etc.

v.alabel/v.llabel:
v.alabel does bulk labeling of areas, v.llable does bulk labeling of
line features. But there is no module to bulk label point features (site
vectors in GRASS terminology). This function is needed if you want to
intersect point features with area features (point-in-polygon test).

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.

Please tell me if i should feed the above bugs/missing features into the
request tracker.

cu,

Andreas

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

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

[neteler]

Hi again,

On Thu, Jan 04, 2001 at 02:35:33PM +0100, Andreas Lange wrote:

Hi,

i wish everyone here a happy new year 2001!

While doing some work with GRASS5.0(beta11/CVS) i discovered some minor
BUGS and some missing features.

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.

s.buffer:
s.buffer is missing, but html-page is still there. s.buffer is IMHO no
longer needed, this is the same than v.circle?

v.circle:
v.circle does echo an error with spearfish - bugsites data, but seems to
work ok. It says something about wrong attributes?

Please try v.bubble - should be an improved version of v.circle.
If v.bubble is the best, let's remove s.buffer and v.circle and rename
v.bubble to v.circle.

s.to.vect:
s.to.vect does not find bugsites@PERMANENT when in users mapset (e. g.
'andreas'), but does not flag this error when in interactive mode. The
module trys always to find the file in the actual mapset, not in the
@PERMANENT mapset. Should be a simple fix.

Mhhh, volunteers?
  

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?

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!

d.save:
d.save does not work with text output (d.text), text is not saved.

-> please report in out new RT...

d.redraw (script):
d.redraw does not work with multiple frames and does not work if d.text
is used (see d.save error).

-> please report in out new RT... When Huidae is back online, he might take
a look.

d.what.rast:
If using d.what.rast slope@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.

gnuplot:
v.to.gnuplot is missing, instead of html-page which is still there.
g.gnuplot is missing, instead of html-page, which is still there. (can't
say if gnuplot inside GRASS is really useful).
The old g.gnuplot works by drawing in a GRASS monitor, which could be
useful for creating histograms etc.

Maybe we better implement "gdchart"?

Chart & Graph tool - C API, perl mod

v.alabel/v.llabel:
v.alabel does bulk labeling of areas, v.llable does bulk labeling of
line features. But there is no module to bulk label point features (site
vectors in GRASS terminology). This function is needed if you want to
intersect point features with area features (point-in-polygon test).

v.slabel? I have added a note into TODO.

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?).

Please tell me if i should feed the above bugs/missing features into the
request tracker.

see above

Thanks for your comments,

Markus

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

[Radim_Blazek2]

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

[Eric_G_Miller]

On Thu, Jan 04, 2001 at 05:10:04PM +0000, Markus Neteler wrote:

> s.buffer:
> s.buffer is missing, but html-page is still there. s.buffer is IMHO no
> longer needed, this is the same than v.circle?
>
> v.circle:
> v.circle does echo an error with spearfish - bugsites data, but seems to
> work ok. It says something about wrong attributes?

Please try v.bubble - should be an improved version of v.circle.
If v.bubble is the best, let's remove s.buffer and v.circle and rename
v.bubble to v.circle.

Well, I can report a small problem I've had with v.bubble. When
generating the buffers based on an attribute, it seems the smallest one
ends up with a zero area degenerate. That wasn't the expected behavior.

I tried to write a version of s.buffer implementing the reported
features from the man page as well as the features of v.circle and
v.bubble. The problem I had was figuring out how to handle overlapping
vector areas and dissolving the common boundaries. It wasn't enough
just to generate a circle and put the area label in the middle, since
v.support would often choke on the results. The available library
routines for a new vector layer weren't much help either.

> s.to.vect:
> s.to.vect does not find bugsites@PERMANENT when in users mapset (e. g.
> 'andreas'), but does not flag this error when in interactive mode. The
> module trys always to find the file in the actual mapset, not in the
> @PERMANENT mapset. Should be a simple fix.
Mhhh, volunteers?

I'll have a look since I worked on that before. Note, s.to.vect is also
broken if the "category" number is a float (since it can't be a float in
the vector world). I'll see if I can work around this as well.

--
Eric G. Miller <egm2@jps.net>

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

[Radim_Blazek2]

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.

Vectors will ignore region except conversion into raster. I think that all vector
modules ignore region now.

> 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?

As I wrote in mail "new vector2" I propose move bounding box from dig
into dig_plus.

> 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.

I think always merge modules if possible.

> v.alabel/v.llabel:
> v.alabel does bulk labeling of areas, v.llable does bulk labeling of
> line features. But there is no module to bulk label point features (site
> vectors in GRASS terminology). This function is needed if you want to
> intersect point features with area features (point-in-polygon test).
v.slabel? I have added a note into TODO.

I want merge into v.category in g51 (and add: delete category, change
category number, ...)
(always merge modules if possible)

> 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?).

Cutting areas is not so simple and we have already v.cutter.
I think that additional option for v.cutter
-r use current region insted of cutter map
should help.
(always merge modules if possible)

Radim

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

[neteler]

On Fri, Jan 05, 2001 at 08:17:21AM +0100, Radim Blazek wrote:

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.
Vectors will ignore region except conversion into raster. I think that all vector
modules ignore region now.

Well, but here we have raster-> vecktor conversion. So sensivity should be
o.k. as the source is raster.

> > 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?
As I wrote in mail "new vector2" I propose move bounding box from dig
into dig_plus.

> > 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.
I think always merge modules if possible.

> > v.alabel/v.llabel:
> > v.alabel does bulk labeling of areas, v.llable does bulk labeling of
> > line features. But there is no module to bulk label point features (site
> > vectors in GRASS terminology). This function is needed if you want to
> > intersect point features with area features (point-in-polygon test).
> v.slabel? I have added a note into TODO.
I want merge into v.category in g51 (and add: delete category, change
category number, ...)
(always merge modules if possible)

> > 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?).
Cutting areas is not so simple and we have already v.cutter.
I think that additional option for v.cutter
-r use current region insted of cutter map
should help.
(always merge modules if possible)

Yes, such an option for v.cutter would be good (and additionally have
v.cutter copying the labels to the new file).

Markus

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

[Andreas_Lange1]

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@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

cu,

Andreas

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

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

[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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

[Andreas_Lange1]

Markus Neteler wrote:

>
> 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?

It works now. I think the problem was that i missed the update, couldn't
compile because of the other error. Thanks a lot.

..

> > > 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.

If i find time, i will try to fix it the way described, as i already
worked on d.what.(vect|rast).

> > > 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...

There are still problems with v.cutter to resolve, this was discussed on
grasslist recently. Sometimes it doesn't work properly. Don't know if i
can check the script in.

cu,

Andreas

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

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