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.
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?
Replying to [comment:3 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...?
I am wondering-- would it be simpler to add a flag to v.drape for
converting vectors to 3D, with all z-values set to some constant? Or
is that not what v.to.3d does?
Dylan
Replying to [comment:3 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...?
Replying to [comment:5 hamish]:
> Replying to [comment:3 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.
Replying to [comment:6 martinl]:
> Replying to [comment:5 hamish]:
> > Replying to [comment:3 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.
Replying to [comment:8 martinl]:
> Replying to [comment:7 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?