[GRASS-user] XY trace plots

John wrote:
> I have an ascii file in .csv format containing x/y coordinates and z
> values. Z column data represents geophysical data collected along
> parallel lines (X and Y coordinates). I wish to display this data in a
> format similar to an XY trace plot (see image example), where z data
> recorded along individual traverses in the field can be displayed as a
> raster image of parallel lines showing both negative and positive
> responses along each line. So far I have imported small data sets using
> both v.in.ascii and v.in.lines with also use of v.build.polylines but
> the results only produce a single flat line. It is most likely I am not
> going the right way about this, hence my query. I have searched the mail
> archive in advance of this mail and found no relevant reference. Is it
> possible to produce such a display with GRASS?

Hamish:

the module has not been written yet, but you might try
importing it with r.in.xyz then interpolating with r.surf.nnbathy
(addons) or one of the other r.surf.* or v.surf.* modules.

Since we can't have missing functionality, I've just added an experimental
module in GRASS addons called r.to.vect.lines. If you can import and
interpolate it into a raster map, you can extract every n-th line as a
3D vector line. With that you can then proceed with Daniel's idea of
displaying it in NVIZ.

   http://grass.osgeo.org/wiki/GRASS_AddOns#r.to.vect.lines

(example using the spearfish elevation map attached)

With your original dataset, if you can know for sure the lines are either
one big continuous one or that they are broken somehow, you might have a
try with the GRASS ascii format described in the v.in.ascii help page.
(format=standard [not the default points import])

good luck,
Hamish

ps- if any python+ctypes experts want to have a look over it please do...
especially to fix the G_is_null_value() call which is currently broken.

(attachments)

nviz_wiggle.png

Hamish wrote:

[...] I've just added an experimental
module in GRASS addons called r.to.vect.lines.

http://grass.osgeo.org/wiki/GRASS_AddOns#r.to.vect.lines

ps- if any python+ctypes experts want to have a look over it please do...
especially to fix the G_is_null_value() call which is currently broken.

The argument must be a pointer, try

G_is_null_value(byref(in_rast[col]), data_type)

or
in_val = in_rast[col]
G_is_null_value(byref(in_val), data_type)

Markus M

Markus wrote:

The argument must be a pointer, try
G_is_null_value(byref(in_rast[col]), data_type)

ah, byref() was missing.

in_rast gets cast()ed early on, hopefully that hasn't cleaned
it away.

thanks,
Hamish

On Sun, May 20, 2012 at 12:11 PM, Hamish <hamish_b@yahoo.com> wrote:

ps- if any python+ctypes experts want to have a look over it please do...

I get a "funny" message effect (the resulting map looks ok):

GRASS 6.4.3svn (nc_spm_08): > g.region rast=elevation
GRASS 6.4.3svn (nc_spm_08): > python r.to.vect.lines.py in=elevation
out=wiggle_lines
Building topology for vector map <wiggle_lines>...
Registering primitives...
135 primitives registered
202500 vertices registered
Building areas...
100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
100%
Number of nodes: 270
Number of primitives: 135
Number of points: 0
Number of lines: 135
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
? complete. <--- ??

The map is correctly produced, it must be some issue in the ctypes interface.

Markus

Hamish wrote:
> ps- if any python+ctypes experts want to have a look
> over it please do...

Markus:

I get a "funny" message effect (the resulting map looks ok):

GRASS 6.4.3svn (nc_spm_08): > g.region rast=elevation
GRASS 6.4.3svn (nc_spm_08): > python r.to.vect.lines.py
in=elevation
out=wiggle_lines
Building topology for vector map <wiggle_lines>...
Registering primitives...
135 primitives registered
202500 vertices registered
Building areas...
100%
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
100%
Number of nodes: 270
Number of primitives: 135
Number of points: 0
Number of lines: 135
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
? complete. <--- ??

The map is correctly produced, it must be some issue in the
ctypes interface.

yes, I saw the same. G_gisinit(argv[0]) is not being accessed/assigned
properly. Does python script+ctypes take care of G_define_module() for
you?

Hamish

Hamish wrote:

yes, I saw the same. G_gisinit(argv[0]) is not being accessed/assigned
properly. Does python script+ctypes take care of G_define_module() for
you?

r.to.vect.lines is using g.parser.

--
Glynn Clements <glynn@gclements.plus.com>