patch proposal: new option for v.category to copy category values from one layer to another

[mlennert]

In the attached patch againts trunk I propose an implementation of a feature in v.category requested regularly in the mailing lists: copying category values from one layer to another.

I don't think that it is a very invasive addition, but someone should probably check before we apply this to trunk. It could possibly also go into 6.5 as it doesn't break backwards compatibility.

I used the word 'transfer' for this option as the way the parser works I needed a word with a different first letter than the others, and 'c'(opy) was already taken by 'c'(hlayer).

On thing I did not put in is a way how to work with type=area. I just exit with a message proposing to use type=centroid to copy category values for areas. If someone wants to implement the same with type=area working, please do so.

Moritz

[mmetz]

copy all cats of first layer to second layer

[mmetz]

Very useful addition, the transfer option!

The attached second patch copies not only the first cat encountered but all cats of the first layer to the second layer. Type = centroid is now automatically activated if type = area and not type=area,centroid.

Markus M

[mlennert]

Replying to mmetz:

Very useful addition, the transfer option!

The attached second patch copies not only the first cat encountered but all cats of the first layer to the second layer. Type = centroid is now automatically activated if type = area and not type=area,centroid.

Thanks, Markus, for looking into this. Can we apply to trunk ? And what about 6.x ?

Moritz

[mmetz]

Replying to mlennert:

Replying to mmetz:

Very useful addition, the transfer option!

The attached second patch copies not only the first cat encountered but all cats of the first layer to the second layer. Type = centroid is now automatically activated if type = area and not type=area,centroid.

Thanks, Markus, for looking into this. Can we apply to trunk ? And what about 6.x ?

I have added the new feature of copying categories in r49413, but with further modifications because the category/layer design of GRASS vectors is quite flexible and thus probably a bit complicated:

• A warning is printed if categories already exist in the target layer (where categories are copied to). This could lead to all sorts of complications. I was contemplating a fatal error, but then I decided to follow GRASS policy: allow a lot, warn if it may be dangerous.
• There is a new hidden feature for option=transfer, if only one layer number is given for the layer option, the module will find the next free layer number and copy categories to that new layer. No danger of confusion with already existing categories in that layer since it's new. This feature is hidden in the sense that it is documented somewhat further down the manual.

Since I was on it, I changed the behaviour of option=chlayer a bit: the layer number of categories is changed (as before) if the current category number does not exist for the target layer, otherwise it is only deleted from the source layer (new). This avoids duplicate category entries of a given geometry object in the target layer.

All changes are tested and should be backported to 6.x since they maintain backwards compatibility and fix an obscure but potentially disastrous bug.

Markus M

[neteler]

trunk and relbr70 are in sync.

Backport of r49413 to G6 still open.

[mlennert]

I don't think that we should still worry about backporting such new functionality. We have a new stable release and we sould rather encourage people to use that if they need this functionality.

So I suggest closing this bug.

[neteler]

Closing as proposed.