#2309: Add a select all flag to v.edit
---------------------------------------+------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: trivial | Milestone: 7.1.0
Component: Vector | Version: svn-trunk
Keywords: v.edit, feature selection | Platform: All
Cpu: Unspecified |
---------------------------------------+------------------------------------
There is no explicit and documented possibility to select all features
when editing using G7:v.edit. This make sense if you edit categories (not
geometry) and you want to change the category for all features.
Perhaps `-a Select all` flag would be a clear way how to say that I want
all features.
Currently you can use the trick with `-r Reverse selection` flag but it is
not readable, intuitive and it is not clear if this behavior is supported.
Another possible workaround is to get bbox by `v.info -g` and pass it as
`polygon` parameter (ticket:2304#comment:2). This seems inconvenient to me
(in Python or in GUI).
There should be a feature in layer 2 with category 10.
{{{
v.what map=test coordinates=913240.0,250614.0
}}}
{{{
East: 913240
North: 250614
------------------------------------------------------------------
Map: test
Mapset: jr_contours
Type: Point
Id: 1
Layer: 1
Category: 1
Layer: 2
Category: 10
}}}
#2309: Add a select all flag to v.edit
--------------------------+---------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: trivial | Milestone: 7.1.0
Component: Vector | Version: svn-trunk
Resolution: | Keywords: v.edit, feature selection
CPU: Unspecified | Platform: All
--------------------------+---------------------------------------
Comment (by mlennert):
I've attached a patch that provides a very simplistic approach to a
"select all" flag. However, reflection is needed on the following
questions:
* Should the flag select all features, regardless of whether they have a
category number of not ?
* If not should the flag select only features that have category numbers
in a given layer ?
I'm sure there are other questions like that that I haven't even thought
about...
#2309: Add a select all flag to v.edit
--------------------------+---------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: trivial | Milestone: 7.1.0
Component: Vector | Version: svn-trunk
Resolution: | Keywords: v.edit, feature selection
CPU: Unspecified | Platform: All
--------------------------+---------------------------------------
Comment (by wenzeslaus):
I added a simple test in Bash which currently uses the `-r` flag as
described in the original report. It would use some review. I'm not really
familiar with format of `v.category` output.
To test run:
{{{
cd vector/v.edit/testsuite
./select_all_flag.sh
}}}
#2309: Add a select all flag to v.edit
--------------------------+---------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: trivial | Milestone: 7.1.0
Component: Vector | Version: svn-trunk
Resolution: | Keywords: v.edit, feature selection
CPU: Unspecified | Platform: All
--------------------------+---------------------------------------
Comment (by wenzeslaus):
Replying to [comment:1 mlennert]:
> I've attached a patch that provides a very simplistic approach to a
"select all" flag.
Thanks.
> However, reflection is needed on the following questions:
>
> * Should the flag select all features, regardless of whether they have a
category number of not ?
> * If not should the flag select only features that have category numbers
in a given layer ?
In the example in the original report, the `layer` option is used to
specify the layer to write the categories to, so it cannot be used for
selection, so there is no "given layer". And since there is no given
layer, there is no way to determine if the features have category or not.
So for me the answer for both questions is select regardless of existing
category. This will do well for simple cases, I'm not sure if there are
any complicated cases when a more sophisticated approach would be
appropriate.