new module: v.to.3d

[hamish]

Hi,

as discussed on the -dev list

​http://thread.gmane.org/gmane.comp.gis.grass.devel/25394/

there is need for a simple way of transforming 2D vectors to 3D vectors.

v.transform will do it, so perhaps the module could be a wrapper function to that?

it should have:

• 2D points + [numeric attr column or value= command line option] -> 3D points
• 2D lines -> 3D lines in a similar way (i.e. labeled contour lines -> 3D)

• a -r flag to reverse the process. If done in a shell script this might be as simple as v.out.ascii | v.in.ascii [without -z]

'v.transform --script' will create the template, and then just a few lines for the wrapper. There is movement to start writing new scripts in Python instead of /bin/sh to aid future portability, but I think the script is simple enough that we could make an initial shell script version which could be considered "disposable with minimal loss of effort."

[Python is problematic as it is not yet a mandatory dependency]

To me it seems the important tasks are collecting the correct command line options needed and getting the module's options and flags out into the users' mind-space. Once that is in place we could rewrite the wrapper as a python script later without much work and without any user visible change.

Hamish

[hamish]

bumping importance to improve chances it gets done for the 6.4.0 release.

Hamish

[martinl]

Initial version of module grass/branches/develbranch_6/scripts/v.to.3d.

TODO: Implement Python version in GRASS7.

Martin

[martinl]

I am not sure which module to use for reverse transformation (3D->2D). Implementation would be easy. I was thinking about v.edit tool=to2d. v.edit is not designed for global operation (like v.clean). Basically it's not problem, just 'selection' parameters (type, cats, ids, where, ...) will be ignored. Any suggestions?

Martin

[martinl]

Replying to martinl:

TODO: Implement Python version in GRASS7.

done grass/trunk/scripts/v.to.3d

[hamish]

Replying to martinl:

I am not sure which module to use for reverse transformation (3D->2D).

points, centroids: v.out.ascii | v.in.ascii (without -z or z=). then you'd need to copy+merge tables adding in the new z column.

polyfeatures: v.out.ascii format=standard | awk to strip away the third column | v.in.ascii format=standard. I think layer/cat setting at end of each feature is ok as it is always like "1 1", never a third column. AFAICT there's no way to keep the data in that 3rd column, as a line can only hold a single attribute/cat. the user can summarize with v.univar if they want that...?

? Hamish

[martinl]

Replying to hamish:

Replying to martinl:

I am not sure which module to use for reverse transformation (3D->2D).

points, centroids: v.out.ascii | v.in.ascii (without -z or z=). then you'd need to copy+merge tables adding in the new z column.

polyfeatures: v.out.ascii format=standard | awk to strip away the third column | v.in.ascii format=standard. I think layer/cat setting at end of each feature is ok as it is always like "1 1", never a third column. AFAICT there's no way to keep the data in that 3rd column, as a line can only hold a single attribute/cat. the user can summarize with v.univar if they want that...?

this approach will be very slow for large vector maps... That's reason why I would prefer to implement it in GRASS C module.

[martinl]

Replying to martinl:

Replying to hamish:

Replying to martinl:

I am not sure which module to use for reverse transformation (3D->2D).

points, centroids: v.out.ascii | v.in.ascii (without -z or z=). then you'd need to copy+merge tables adding in the new z column.

polyfeatures: v.out.ascii format=standard | awk to strip away the third column | v.in.ascii format=standard. I think layer/cat setting at end of each feature is ok as it is always like "1 1", never a third column. AFAICT there's no way to keep the data in that 3rd column, as a line can only hold a single attribute/cat. the user can summarize with v.univar if they want that...?

this approach will be very slow for large vector maps... That's reason why I would prefer to implement it in GRASS C module.

Another option would be to rewrite v.to.3d in C.

[martinl]

Replying to martinl:

Another option would be to rewrite v.to.3d in C.

Done in r35052 (devbr6) and r35053 (trunk). Not backported to relbr64, should be:

• now
• after final 6.4.0
• never

?

Martin

[martinl]

Replying to martinl:

Replying to martinl:

Another option would be to rewrite v.to.3d in C.

Done in r35052 (devbr6) and r35053 (trunk). Not backported to relbr64, should be:

• now
• after final 6.4.0
• never

I would suggest to replace Bash script with C module also in releasebranch_6_4. Any objections?

Martin

[martinl]

Replying to martinl:

I would suggest to replace Bash script with C module also in releasebranch_6_4. Any objections?

done in r35304.