On Mar 2, 2008, at 12:03 PM, grass-dev-request@lists.osgeo.org wrote:
Date: Sun, 2 Mar 2008 09:24:52 -0800
From: Dylan Beaudette <dylan.beaudette@gmail.com>
Subject: Re: [GRASS-dev] 2D to 3D points
To: grass-dev@lists.osgeo.org
Cc: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
Message-ID: <200803020924.52526.dylan.beaudette@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Saturday 01 March 2008 10:20:45 pm Hamish wrote:
Benjamin Ducke wrote:
That should work but it may not exactly be easy to locate for a
novice user.
How about a little wrapper script for v.transform that simplifies
this action?
I am increasingly concerned about the number of, sometimes basic,
geoprocessing functions that are present in GRASS but "hidden"
in complex module options. Of course people can always mail to
this list but in the first place it will create frustration for
them and possible turn them away.
So we make little wrapper scripts like v.dissolve and v.centroids.
That's much better than dealing with code duplication.
but that shouldn't wrap 3 module commands together with temporary maps
etc to perform something as simple as the 2d+attr column -> 3d points
conversion. If as Maciek suggests v.transform could do the job then
it's not so bad. The v.transform name even sounds right for the job.
Hamish
I agree that we should avoid code duplication at any cost, and v.transform
does the job. However, doesn't it make more sense to put that code (for
points) into v.extrude ? Or, is v.extrude primarily for areas by design?
Dylan
IMHO, v.type is a much better place to put this. v.type is already designed to transform vector objects from one type of vector object to another. Changing a vector object from a 2D point to a 3D point seems to fit this concept well. (And while we're at it, v.type should be changed to work like v.type.sh).
v.transform is really a georectifying module for vector objects. It's a conceptual stretch to include transforming 2D to 3D points there--though it does work.
v.extrude is designed to extrude a 'flat' object into a 3-dimensional space--primarily polygon to polyhedron. Following this concept, it should extrude a line into a 'wall' and a point into a 1-dimensional 'pole'. It is not aimed at repositioning dimensionless points in 3D space.
>> Benjamin Ducke wrote:
>>> How about a little wrapper script for v.transform that simplifies
>>> this action?
Dylan:
> However, doesn't it make more sense to put that code (for
> points) into v.extrude ? Or, is v.extrude primarily for areas
> by design?
Michael:
IMHO, v.type is a much better place to put this. v.type is already
designed to transform vector objects from one type of vector object
to another. Changing a vector object from a 2D point to a 3D point
seems to fit this concept well.
As the functionality is already written into a C module, and v.type is
not conspicuously missing the feature or obviously+naturally matching
the task, IMO it is better to use a simple wrapper script with an
obvious+natural name.
I wonder if such a script could call another module for the reverse
proceedure? (v.out.ascii directly piped back into v.in.ascii (without
-z)?, or v.transform + db.in.ogr? or some new C code?)
for the 2D -> 3D case the clearest way would be to pipe
'v.out.ascii.db | v.in.ascii -z' and then copy the table. But to do
that properly v.out.ascii would need to finally to have the DB output
code written. (probably pretty simple to do; the v.out.ascii.db script
can be found in wiki addons)
(And while we're at it, v.type should
be changed to work like v.type.sh).
the module command line interface can't change until GRASS 7.
Hence we have v.type.sh, for once it's not due to long queues.
v.transform is really a georectifying module for vector objects. It's
a conceptual stretch to include transforming 2D to 3D points there--
though it does work.
Hence using a wrapper function with a more intuitive name and only
expose the relevant options.
How about a little wrapper script for v.transform that simplifies
this action?
Dylan:
However, doesn't it make more sense to put that code (for
points) into v.extrude ? Or, is v.extrude primarily for areas
by design?
Michael:
IMHO, v.type is a much better place to put this. v.type is already
designed to transform vector objects from one type of vector object
to another. Changing a vector object from a 2D point to a 3D point
seems to fit this concept well.
As the functionality is already written into a C module, and v.type is
not conspicuously missing the feature or obviously+naturally matching
the task, IMO it is better to use a simple wrapper script with an
obvious+natural name.
I wonder if such a script could call another module for the reverse
proceedure? (v.out.ascii directly piped back into v.in.ascii (without
-z)?, or v.transform + db.in.ogr? or some new C code?)
for the 2D -> 3D case the clearest way would be to pipe
'v.out.ascii.db | v.in.ascii -z' and then copy the table. But to do
that properly v.out.ascii would need to finally to have the DB output
code written. (probably pretty simple to do; the v.out.ascii.db script
can be found in wiki addons)
(And while we're at it, v.type should
be changed to work like v.type.sh).
the module command line interface can't change until GRASS 7.
Hence we have v.type.sh, for once it's not due to long queues.
v.transform is really a georectifying module for vector objects. It's
a conceptual stretch to include transforming 2D to 3D points there--
though it does work.
Hence using a wrapper function with a more intuitive name and only
expose the relevant options.
Hamish,
In the past, this would be the easiest solution. However, I'm increasingly reluctant to create more Bash scripts for GRASS given the plans to move away from that platform and the problems with running scripts under Windows/MSys now.
>> v.transform is really a georectifying module for vector objects.
>> It's a conceptual stretch to include transforming 2D to 3D points
>> there-- though it does work.
Hamish:
> Hence using a wrapper function with a more intuitive name and only
> expose the relevant options.
Michael:
In the past, this would be the easiest solution. However, I'm
increasingly reluctant to create more Bash scripts for GRASS given
the plans to move away from that platform and the problems with
running scripts under Windows/MSys now.
using 'g.module --script' + the fact that it is apparently a one-liner
v.transform process means the script would only take about 2 minutes to
write. So little investment in bash and easily replaced when the time
comes.
We can't/shouldn't make python a mandatory dependency until GRASS 7. If
we do it in bash now (then rewrite as python later) it gets the
functionality out there now and allows the solution to start leaking
into people's minds and work. The user shouldn't notice if the back-end
language changes at some point if the interface stays the same.
This is not to say we can't start to develop shadow g.module.py
versions of scripts now! That would give us a good head start and help
spread the load in time.