It is really confusing, I am not sure how to solve it. Do you think,
would be enough to print a given warning, e.g. "The layer number (2)
and layer number for labels (1) are not the same.".
Best, Martin
PS: I am really looking forward to the new bug tracker! Thanks Maciek
for working on it...
It is really confusing, I am not sure how to solve it. Do you think,
would be enough to print a given warning, e.g. "The layer number (2)
and layer number for labels (1) are not the same.".
It would appear to be perfectly legal to display shapes from one layer
and labels from another. So if this should be mentioned at all, it
should use G_message and not G_warning? (so --quiet makes it go away)
At minimum the label section of the d.vect help page needs to clarify
this.
Martin Landa wrote:
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219
> > -------------------------------------------------------------------
..
> It seems you have to specify the llayer parameter too, e.g.
>
> d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2
>
> It is really confusing, I am not sure how to solve it. Do you think,
> would be enough to print a given warning, e.g. "The layer number (2)
> and layer number for labels (1) are not the same.".
It would appear to be perfectly legal to display shapes from one layer
and labels from another. So if this should be mentioned at all, it
should use G_message and not G_warning? (so --quiet makes it go away)
At minimum the label section of the d.vect help page needs to clarify
this.
I agree with you, the similar patch (note: without doc update)?
... oops, I forgot to test DISP_CAT, etc. The updated patch attached.
Martin
2006/12/4, Martin Landa <landa.martin@gmail.com>:
Hi,
2006/12/4, Hamish <hamish_nospam@yahoo.com>:
> Martin Landa wrote:
> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5219
> > > -------------------------------------------------------------------
> ..
> > It seems you have to specify the llayer parameter too, e.g.
> >
> > d.erase;d.vect pts2 layer=2 display=shape,cat llayer=2
> >
> > It is really confusing, I am not sure how to solve it. Do you think,
> > would be enough to print a given warning, e.g. "The layer number (2)
> > and layer number for labels (1) are not the same.".
>
> It would appear to be perfectly legal to display shapes from one layer
> and labels from another. So if this should be mentioned at all, it
> should use G_message and not G_warning? (so --quiet makes it go away)
> At minimum the label section of the d.vect help page needs to clarify
> this.
I agree with you, the similar patch (note: without doc update)?
It is really confusing, I am not sure how to solve it. Do you think,
would be enough to print a given warning, e.g. "The layer number (2)
and layer number for labels (1) are not the same.".
It would appear to be perfectly legal to display shapes from one layer
and labels from another.
Hamish is correct. However, it seems to me that when the user runs:
d.vect pts2 layer=2 display=shape,cat
he will expect that categories for layer 2 will be displayed, not for
layer 1, as it happens currently. Only if he really wants to display
geometry from layer 2 and categories (or other labels) belonging to
layer 1, he should have to explicitely set llayer=1.
The conclussion is, if my thinking is correct: shouldn't llayer default
to layer, if not explicitely requested differently?
If this was implemented, the warning which Matin proposed in his patch
would be redundant.
he will expect that categories for layer 2 will be displayed, not for
layer 1, as it happens currently.
as it happens currently if the user sets llayer incorrectly (by not
setting it at all).
Only if he really wants to display geometry from layer 2 and
categories (or other labels) belonging to layer 1, he should have to
explicitely set llayer=1.
The conclussion is, if my thinking is correct: shouldn't llayer
default to layer, if not explicitely requested differently?
easier said than done; the parser can't know before hand what the answer
to another option will be. but it is possible to give it no default and
add to the llayer's option description that it will use the layer= answer
if not given. While possible, I'm still not sure if it's advisable. (shrug)
easier said than done; the parser can't know before hand what the answer
to another option will be. but it is possible to give it no default and
add to the llayer's option description that it will use the layer= answer
if not given. While possible, I'm still not sure if it's advisable. (shrug)
it could be implemented like this (see the patch) for example. Just I
am also not sure, maybe it is better for the user to set up the llayer
according to layer parameter(?)
I vote for using layer number given by the layer parameter as default
layer number for labels.
Martin
2007/2/19, Martin Landa <landa.martin@gmail.com>:
Hi,
2007/2/19, Hamish <hamish_nospam@yahoo.com>:
> easier said than done; the parser can't know before hand what the answer
> to another option will be. but it is possible to give it no default and
> add to the llayer's option description that it will use the layer= answer
> if not given. While possible, I'm still not sure if it's advisable. (shrug)
it could be implemented like this (see the patch) for example. Just I
am also not sure, maybe it is better for the user to set up the llayer
according to layer parameter(?)
I vote for using layer number given by the layer parameter as default
layer number for labels.
Martin
2007/2/19, Martin Landa <landa.martin@gmail.com>:
Hi,
2007/2/19, Hamish <hamish_nospam@yahoo.com>:
easier said than done; the parser can't know before hand what the answer
to another option will be. but it is possible to give it no default and
add to the llayer's option description that it will use the layer= answer
if not given. While possible, I'm still not sure if it's advisable. (shrug)
it could be implemented like this (see the patch) for example. Just I
am also not sure, maybe it is better for the user to set up the llayer
according to layer parameter(?)
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
but there is used G_define_standard_option(G_OPT_V_FIELD)
(G_define_option() could be used also) which sets answer to "1". Not
sure if I understand well.
Regards,
Martin
2007/2/19, Hamish <hamish_nospam@yahoo.com>:
Martin Landa wrote:
> + lfield_opt->answer = NULL;
Not needed. G_define_option() sets that to null already.
I committed the changes to CVS (I used G_define_option() instead of
G_define_standard_option()). Closing the bugs/wishes number 4004 and
5219.
Martin
2007/2/20, Martin Landa <landa.martin@gmail.com>:
Hi,
but there is used G_define_standard_option(G_OPT_V_FIELD)
(G_define_option() could be used also) which sets answer to "1". Not
sure if I understand well.
Regards,
Martin
2007/2/19, Hamish <hamish_nospam@yahoo.com>:
> Martin Landa wrote:
> > + lfield_opt->answer = NULL;
>
> Not needed. G_define_option() sets that to null already.
>
> Hamish
>
* the changes which I made in CVS have no connection with this bug
* on the other hand, it seems to work OK for me (i.e. I cannot
reproduce described behaviour)
Martin
2007/2/20, Martin Landa <landa.martin@gmail.com>:
Hi,
I committed the changes to CVS (I used G_define_option() instead of
G_define_standard_option()). Closing the bugs/wishes number 4004 and
5219.
Martin
2007/2/20, Martin Landa <landa.martin@gmail.com>:
> Hi,
>
> but there is used G_define_standard_option(G_OPT_V_FIELD)
> (G_define_option() could be used also) which sets answer to "1". Not
> sure if I understand well.
>
> Regards,
>
> Martin
>
> 2007/2/19, Hamish <hamish_nospam@yahoo.com>:
> > Martin Landa wrote:
> > > + lfield_opt->answer = NULL;
> >
> > Not needed. G_define_option() sets that to null already.
> >
> > Hamish
> >
>
> --
> Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
>