How to add 3D without breaking script compatibility in v.edit? (Was: Re: [GRASS-dev] Patch to make v.edit partially 3D)

Martin Landa landa.martin at
Thu Sep 10 04:18:34 EDT 2009


2009/9/9 Harri Kiiskinen <harri.kiiskinen at>:

>>> 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


Martin Landa <landa.martin> *

More information about the grass-dev mailing list