[GRASS-dev] Re: r.surf.nnbathy + v.out.ascii?

[Maciej Sieczka]

Hamish wrote:
>> Hamish wrote:
>>> I've added a new -r flag and fs= option to v.out.ascii in CVS which
>>> may make it more appropriate than having to run v.to.rast first to
>>> make a raster grid.
> 
> Maciej Sieczka wrote:
>> But if the input is contour lines? Rasterising it and interpolating
>> the raster seems the best way to go.
> ..
>> Like I said - this would work only with vector points I guess. Please
>> correct me if I'm wrong.

> "v.out.ascii format=points" (the default) only outputs points of course;
> I guess you could do "v.to.points -v" or "v.out.ascii format=standard" 
> +unix tools to get vector contour lines as xyz file.
> 
> But yes, for vector contour lines r.to.vect isn't so bad an option.

Not only "not so bad" but better than exporting contor lines as a list
of vertices - because the list of vertices on a line doesn't include
the coordinates *between* the vertices. I thought of v.to.points -i as
a workaround, but it's less reliable (out of memory on few milion
points, how to manage points spacing vs grid spacing and avoid doubled
input points per cell, slower than r.to.vect+r.stats -1gn).

> How do results compare to r.surf.contour*?

In short words, r.surf.contour doesn't compare to nnbathy :).

1. nnbathy deals OK with combined input of contour lines and points.
Elevation points can be located anywhere, including between contour
lines (r.surf.contour chokes on that).

2. The contour lines can be disjointed.

3. Faster.

4. nnbathy output is always continous; r.surf.contour happens to break
continuity on more complex input and on bigger no data gaps.

The problem with nnbathy is that it might produce artifact flat areas
on kidney shaped contour lines. This is a general issue with natural
neighbor interpolators and triangulation (natural neighbor is kind off
smoothed triangulation).

A thing to remember is that as natural neighbor is an exact
interpolator, the surface it creates will go exactly through all the
input points. And since it connects them linearely, the output happens
to be "rough". However, natneigh will never under- or overshoot - which
I prefer greatly over a nice smooth surface, which has over- and
undershoots by desing. For the same reason natneigh will handle any
gradient in clustered input just OK (eg. a cliff next to a plain
beach). And it will never break continuity on huge areas lacking input
data.

Another thing to remember is that if you don't have a spot of elevation
  inside your closed contour line, natneigh will interpolate a perfect
flat area inside (like r.surf.contour does). I don't consider it a
defect. Because it let's you interpolate flat areas where you need
them. If you want a nice hilltop or a hollow in the ground, you need to
place a spot of appropriate elevation as needed.

Summarising, natneigh interpolation is not trying to be wiser than
input data - it just follows it. Thus if you feed good data in, you'll
get a good result. And in advance you can predict what the output will be.

> [*] problems with r.surf.contour: 0 in input data is treated as null,
> integer output only.

Know that. nnbathy doesn't have this problems either.

Maciek