[GRASS-dev] Patch to make v.edit partially 3D

Dear All,

this is my first try in producing a patch for GRASS, so please bear with me...

The module v.edit includes the tools 'move' and 'vertexmove', that use
routines from the vector editing library 'vedit'. These routines are
already capable of performing these changes in 3D, and the only
changes are needed in the user interface of v.edit.

The attached file is a product of "svn diff" that shows the changes in
module 'v.edit' in 'trunk'.

If someone feels this is useful, please feel free to apply the
changes. I do not normally use svn for anything, so if there's a
better way to do this thing, just let me know.

Best,

Harri K.

--
Harri Kiiskinen (harkiisk[at]gmail.com)

(attachments)

v_edit_move_3d.diff (2.68 KB)

Hi,

2009/9/8 Harri Kiiskinen <harkiisk@gmail.com>:

[...]

If someone feels this is useful, please feel free to apply the
changes. I do not normally use svn for anything, so if there's a
better way to do this thing, just let me know.

committed to trunk (r39093) and devbr6 (r39094). One drawback is that
'move' parameter requires 3rd coordinate also for 2D vectors...

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Hi,

2009/9/9 Harri Kiiskinen <harri.kiiskinen@utu.fi>:

If someone feels this is useful, please feel free to apply the
changes. I do not normally use svn for anything, so if there's a
better way to do this thing, just let me know.

committed to trunk (r39093) and devbr6 (r39094). One drawback is that
'move' parameter requires 3rd coordinate also for 2D vectors...

Thanks! Yes, this change is incompatible with earlier versions of
GRASS, and I do not like it, but could not find an obvious solution to

right, reverted in r39105 (devbr6).

the problem. If there was a way to make the third coordinate
optional (like key_desc="like x,y[,z]", which I don't think
there is), that would be a solution. One way would be

This could be done in trunk, it requires changes in the parser.
Probably such changes will be not backported to devbr6.

to introduce a new flag (like -z) to indicate 3D-operation, but in
that case, I don't see how the command line could be 'pre-parsed' for
this flag so that the 'move' parameter could be given the correct
form. A third option would be to add a new parameter, something like

Hm, right it will not solve key_desc problem.

'move3' to provide 3D-coordinates.

The same problem affects also the parameters 'coord', and 'bbox', and
even more so, as both currently accept multiple pairs of coordinates.

I don't like this solution, but probably it is the only one reasonable
solution for grass65 since we don't expect changes in the parser.

So the solution adopted now should be the same for these, later on. (A
problem I'm tempted to pay some attention to, too, as v.edit
3D functionality would be of some use.)

Perhaps the safest and most compatible way would actually be to
introduce new parameters for single and multiple 3D coordinate
triples? (In practice, addition of 'move3', 'coord3' and 'bbox3'.) Any
comments? Suggestions?

I have no better idea for GRASS 6.5 (please correct me if you have
better one). In GRASS 7.0 it would be cool to change the parser to
support optional key_desc item, so x,y,[z] requires at least 2 or 3
items.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa