[GRASSLIST:834] Re: Planning swath bathymetry surveys

[Hamish]

> I tried to put together a little script to test out some ideas. Things
> worked OK to a point. I ran into limits on the number of segments I
> could add to a line with v.split which limits the resolution of the
> resulting swath map. I also ran into problems with v.buffer which did
> not buffer the lines in the way I would expect. I put together a web
> page with a visual of what I mean (use the script copied below):
> 
> http://david.p.finlayson.googlepages.com/swathwidth
> 
> I would love to hear any comments on how to do this better.

v.what.rast maybe more efficient than of v.drape steps?
Instead of v.to.rast at the end, make a vector "hull" with 
'v.extract -d' or v.hull?


1) "It appears that v.buffer buffers the nodes on the line segments
rather than drawing parallel lines at the appropriate distance from
the centerline."

I don't think that is right, if the input feature is a line.
If the input features are points, then of course.
v.buffer bufcol= is not bug free. Nothing like you describe though.
But are you buffering points, not lines ?!

If bulcol= is the problem, use a loop: for each point v.buffer+v.patch.


"2) v.split out-of-memory errors?
 I found that v.split can not segment an input line into an arbitrary
number of segments. The upper bound seems to be <1000 segments per line
before getting an out of memory error."

Sounds like a memory leak, can you file a bug report?

maybe you could try using "valgrind" to see what's filling up?
 http://bambi.otago.ac.nz/hamish/grass/memleak/v.in.ascii/


"3) v.db.addtable sends weird messages to the screen:
First, it posts an ERROR that the table I am about to create does not
exist. Isn't the whole point of v.db.addtable to create a new table??"

Known issue. I had thought there was something in the script or help 
page that told you to ignore those errors, but I can't find it now.
They are harmless.

Probably better use of "2>&1 > /dev/null" in the script is needed.

The script tests to see if a table is connected before adding a new 
layer, the errors happen then if it doesn't find one. Based on the 
return code it either does one thing or another. stderr can (carefully)
be redirected to /dev/null on the query steps to silence these.


"Second, it posts a WARINING that the attached table can be deleted if
the vector is deleated. I would resurve the keyword WARNING for
processes that have completed with errors. In this case, this is just a
Note from the creater of the script not to hurt yourself and has nothing
to do with the actual process of v.db.addtable at all. I would recommend
changing the wording to NOTE or CAUTION or better yet, put this info in
the manual where it belongs and don't clutter up the command line with
it (we get the picture the second time we use the command)."

This is given by v.db.connect, which v.db.addtable calls.

If you have connected to an outside table it is very important to know 
that the table will be removed if the map is removed! If the GIS created
the table just for the map, then it's not so much of a problem.

In this case the existing table we connect to is the one we just made,
so the warning can probably be sent to /dev/null. But if there is a
real error you will then miss it.



Hamish