Opened 12 years ago

Closed 11 years ago

#82 closed task (fixed)

new module: v.to.3d

Reported by: hamish Owned by: martinl
Priority: major Milestone: 6.4.0
Component: Vector Version: svn-develbranch6
Keywords: Cc: grass-dev@…
CPU: Unspecified Platform: Unspecified

Description

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

Change History (10)

comment:1 Changed 11 years ago by hamish

Component: defaultVector
CPU: Unspecified
Platform: Unspecified
Priority: minormajor
Type: enhancementtask
Version: svn-trunksvn-develbranch6

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

Hamish

comment:2 Changed 11 years ago by martinl

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

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

TODO: Implement Python version in GRASS7.

Martin

comment:3 Changed 11 years ago by 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

comment:4 in reply to:  2 Changed 11 years ago by martinl

Replying to martinl:

TODO: Implement Python version in GRASS7.

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

comment:5 in reply to:  3 ; Changed 11 years ago by 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

comment:6 in reply to:  5 ; Changed 11 years ago by 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.

comment:7 in reply to:  6 ; Changed 11 years ago by 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.

comment:8 in reply to:  7 ; Changed 11 years ago by 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

comment:9 in reply to:  8 ; Changed 11 years ago by 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

comment:10 in reply to:  9 Changed 11 years ago by martinl

Resolution: fixed
Status: assignedclosed

Replying to martinl:

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

done in r35304.

Note: See TracTickets for help on using tickets.