I am not sure if this behaviour is preferred from user POV. Would you prefer
1) to keep current behaviour
2) delete attributes when deleting features automatically
3) delete attributes only optionally (eg. tool=deleteattr" or special flag).
Similarly for `tool=add` which do not add new record to the table.
Hi,
My vote goes to option 3); flag implemented with default behaviour corresponding to option 2) if possible (attributes deleted by default).
Thanks, Martin.
Best regards,
Ismael G.
Ingeniero de Caminos (UPM). Ingénieur des Ponts et Chaussées (ENPC).
PhD researcher @ Urban & Land Planning Department @ ETSICCPM UPM www.caminos.upm.es +34 91 336 67 83
I am not sure if this behaviour is preferred from user POV.
Would you prefer
1) to keep current behaviour
2) delete attributes when deleting features automatically
3) delete attributes only optionally (eg. tool=deleteattr"
or special flag).
my 2c:
-a flag is a good idea.
-be non-destructive by default.
-for backwards compatibility of behaviour with gr6 probably 'don't delete'
would have to be the default.
-if it deleted by default in grass7 make the flag a different letter to
avoid destroying data by bad assumptions or reusing an old gr6 script.
does v.edit actually delete the line feature or just tag them as "dead"?
Similarly for `tool=add` which do not add new record to the
table.
note that some maps do not have categories on purpose, and when adding
there are many options (next not used, certain value, step size, etc).
no point in stuffing all of v.category's functionality into v.edit.
Keep It Simple and Stupid.
In a way it depends on your view of what v.edit should be. Is it a do-one-
thing well low-level coordinate-feature editor, or is the fat swiss army
knife with the magnifying glass and the kitchen sink? (not sure if that
phrase translates from english well
editing maps in place scares me a bit as you are in trouble if something
goes wrong, so I tend to use the multistep process even if it is a bit
annoying to have a long chain of in=a out=b in=b out=c in=c out=d +
g.remove at the end. .... save the edits in a version control way
(e.g. temporal property line changes where you want to keep a record of
what changed, who changed it, when, etc) would be a hugely hugely
important feature to add to GRASS, but it would take a lot of work.
Can PostGIS work in a transactional database + change history way?
[I digress but that idea is very important, big demand is out there for
it, and I've been meaning to write about it for a while....]
I am not sure if this behaviour is preferred from user POV. Would you prefer
1) to keep current behaviour
2) delete attributes when deleting features automatically
3) delete attributes only optionally (eg. tool=deleteattr" or special flag).
If you delete attributes, please keep in mind that other features can
have the same category like the feature to be deleted, in this case
attributes should not be deleted because they are still used by other
features.
Markus M
Similarly for `tool=add` which do not add new record to the table.
