Is there some way I've missed to change 2D points with a z attribute field, into 3D points without reimporting them?
Micahel
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Thursday 28 February 2008, Michael Barton wrote:
Is there some way I've missed to change 2D points with a z attribute
field, into 3D points without reimporting them?Micahel
v.extrude... not sure if it works with points yet.
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
It doesn't seem to. I think it makes columns from the points. I just want the points in 3D xyz space.
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Feb 28, 2008, at 3:39 PM, Dylan Beaudette wrote:
On Thursday 28 February 2008, Michael Barton wrote:
Is there some way I've missed to change 2D points with a z attribute
field, into 3D points without reimporting them?Micahel
v.extrude... not sure if it works with points yet.
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Hi,
2008/2/28, Dylan Beaudette <dylan.beaudette@gmail.com>:
On Thursday 28 February 2008, Michael Barton wrote:
> Is there some way I've missed to change 2D points with a z attribute
> field, into 3D points without reimporting them?
>
> Micahel
Dylan:
v.extrude... not sure if it works with points yet.
"points become 3D vertical lines, lines to 3D lines, boundaries to
faces and areas to faces and kernel"
http://grass.osgeo.org/grass63/manuals/html63_user/v.extrude.html
If there is no way how to convert 2D point to 3D points there could be
special flag for this(?)
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
On Feb 28, 2008, at 4:27 PM, Martin Landa wrote:
If there is no way how to convert 2D point to 3D points there could be
special flag for this(?)
It would seem that this would be an increasingly common task. I know that I've run into it several times lately. Most recently, I've needed this to convert 2D points to 3D to run through v.surf.bspline. It doesn't seem to work correctly using the column option, but does very nice interpolations using 3D points.
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton pisze:
It doesn't seem to. I think it makes columns from the points.
If the input is a 3d point it makes a vertical 3d line out of it (the lines's 2d length = 0, 3d length = 0 + input 3d point's z). As the manual says. It takes 2 additional commnads to extract the top node:
v.extrude input=pt output=pt3d_ln hcolumn=wys type=point layer=1
v.to.points -n input=pt3d_ln output=pt3d_pt type=line llayer=1
v.extract input=pts3d_pt output=pts3d_pt_top type=point layer=2 new=-1 where="along>0"
For tranforming 2d points into 3d directly there is v.transform I guess, using 'table' and 'columns' option.
Maciek
Hi,
2008/2/29, Maciej Sieczka <tutey@o2.pl>:
[snip]
For tranforming 2d points into 3d directly there is v.transform I guess,
using 'table' and 'columns' option.
right, v.transform could do the job
v.transform -t in= out= zshift=
or
v.transform -t in= out= col='zshift:col_name'
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
Thanks Maciej.
However, the 1st solution will take as long (maybe longer) than importing the points from their original file again. I'll see if v.transform will do it in one step.
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On Feb 29, 2008, at 12:14 AM, Maciej Sieczka wrote:
Michael Barton pisze:
It doesn't seem to. I think it makes columns from the points.
If the input is a 3d point it makes a vertical 3d line out of it (the lines's 2d length = 0, 3d length = 0 + input 3d point's z). As the manual says. It takes 2 additional commnads to extract the top node:
v.extrude input=pt output=pt3d_ln hcolumn=wys type=point layer=1
v.to.points -n input=pt3d_ln output=pt3d_pt type=line llayer=1
v.extract input=pts3d_pt output=pts3d_pt_top type=point layer=2 new=-1 where="along>0"
For tranforming 2d points into 3d directly there is v.transform I guess, using 'table' and 'columns' option.
Maciek
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.
Benjamin
Maciej Sieczka wrote:
Michael Barton pisze:
It doesn't seem to. I think it makes columns from the points.
If the input is a 3d point it makes a vertical 3d line out of it (the lines's 2d length = 0, 3d length = 0 + input 3d point's z). As the manual says. It takes 2 additional commnads to extract the top node:
v.extrude input=pt output=pt3d_ln hcolumn=wys type=point layer=1
v.to.points -n input=pt3d_ln output=pt3d_pt type=line llayer=1
v.extract input=pts3d_pt output=pts3d_pt_top type=point layer=2 new=-1 where="along>0"
For tranforming 2d points into 3d directly there is v.transform I guess, using 'table' and 'columns' option.
Maciek
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
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
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
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
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Thu, Feb 28, 2008 at 11:26 PM, Michael Barton <michael.barton@asu.edu> wrote:
Is there some way I've missed to change 2D points with a z attribute
field, into 3D points without reimporting them?
I did it like this (borrowed from 3rd GRASS book, p. 211 - NC data set):
# work on map in current mapset
g.copy vect=precip_30ynormals,precip_30ynormals_tmp
v.info -c precip_30ynormals_tmp
v.db.addcol precip_30ynormals_tmp \
col="x double precision, y double precision"
v.to.db precip_30ynormals_tmp option=coor col=x,y
# we assume that the table name corresponds to input map name
v.in.db precip_30ynormals_tmp out=myprecip_30ynormals \
x=x y=y z=elev key=cat
v.db.select myprecip_30ynormals
# We can now remove the superfluous 'x' and 'y' columns from the table:
v.db.dropcol myprecip_30ynormals col=x
v.db.dropcol myprecip_30ynormals col=y
v.info -c myprecip_30ynormals
v.db.select myprecip_30ynormals
v.info myprecip_30ynormals
g.remove vect=precip_30ynormals_tmp
# The new map myprecip_30ynormals now contains 3D geometry.
To have this a bit simpler would be great.
Markus
As far as I am aware, the term "extrusion" is pretty well defined
as the operation of extending an object in 3D space by "pulling
it out" with a predefined bearing and length. This would convert a point
to a line, a line to a plane and a polygon to, well, a polygon with a
volume, I guess.
Personally, I'd be more in favour of wrapping a little script
"v.points.to.3d" around v.transform. For the beginners' sake.
Benjamin
Dylan Beaudette wrote:
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
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
On Sunday 02 March 2008, Benjamin Ducke wrote:
As far as I am aware, the term "extrusion" is pretty well defined
as the operation of extending an object in 3D space by "pulling
it out" with a predefined bearing and length. This would convert a point
to a line, a line to a plane and a polygon to, well, a polygon with a
volume, I guess.Personally, I'd be more in favour of wrapping a little script
"v.points.to.3d" around v.transform. For the beginners' sake.Benjamin
Well from that 'angle' I think that it makes sense not to use v.extrude.
v.points.to.3d seems like a fine choice.
Cheers,
Dylan
Dylan Beaudette wrote:
> 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
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Benjamin wrote:
> As far as I am aware, the term "extrusion" is pretty well defined
> as the operation of extending an object in 3D space by "pulling
> it out" with a predefined bearing and length. This would convert a
> point to a line, a line to a plane and a polygon to, well, a
> polygon with a volume, I guess.
>
> Personally, I'd be more in favour of wrapping a little script
> "v.points.to.3d" around v.transform. For the beginners' sake.
Dylan:
Well from that 'angle' I think that it makes sense not to use
v.extrude.
v.points.to.3d seems like a fine choice.
'til now we have manged to keep the "."s in official modules to a max
of two.
see previous discussion:
http://article.gmane.org/gmane.comp.gis.grass.devel/13714
http://article.gmane.org/gmane.comp.gis.grass.devel/13739
v.to.3dpoints or v.points.3d?
It doesn't match v.to.rast,v.to.rast3 naming, but I think v.to.points3
would make it too close to v.to.points which is another task
completely.
But it is not so far from what v.to.rast3 does, so maybe not so bad.
(shrug)
to get a nifty instant prefab wrapper script do:
v.transform --script
Changing topic slightly, how about adding a -z flag to v.to.points for
3D lines? (no DB column involved)
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
On Sunday 02 March 2008, Hamish wrote:
Benjamin wrote:
> > As far as I am aware, the term "extrusion" is pretty well defined
> > as the operation of extending an object in 3D space by "pulling
> > it out" with a predefined bearing and length. This would convert a
> > point to a line, a line to a plane and a polygon to, well, a
> > polygon with a volume, I guess.
> >
> > Personally, I'd be more in favour of wrapping a little script
> > "v.points.to.3d" around v.transform. For the beginners' sake.Dylan:
> Well from that 'angle' I think that it makes sense not to use
> v.extrude.
> v.points.to.3d seems like a fine choice.'til now we have manged to keep the "."s in official modules to a max
of two.see previous discussion:
http://article.gmane.org/gmane.comp.gis.grass.devel/13714
http://article.gmane.org/gmane.comp.gis.grass.devel/13739v.to.3dpoints or v.points.3d?
Right-- better to stick to established conventions. Any name is ok with me.
v.points.3d sounds good.
It doesn't match v.to.rast,v.to.rast3 naming, but I think v.to.points3
would make it too close to v.to.points which is another task
completely.
But it is not so far from what v.to.rast3 does, so maybe not so bad.
(shrug)to get a nifty instant prefab wrapper script do:
v.transform --scriptChanging topic slightly, how about adding a -z flag to v.to.points for
3D lines? (no DB column involved)
sounds like a useful option.
cheers,
Dylan
Hamish
___________________________________________________________________________
_________ Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341