Frank, is there a description of the way the smoothing is done, or
should I look it up in the code?
BTW: there is a description of the algorithm used in GRASS to create
contour lines:
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.contour/README
This looks much more adapted to the specific case of contour lines than
the general weighted distance model in GDAL (which is the best one for
general purposes IMHO). Would it make sense/be possible to adapt the
GRASS code for GDAL? Doesn't look all too difficult to me.
Jan
On 03/29/10 18:37, Frank Warmerdam wrote:
Christopher Barker wrote:
Even Rouault wrote:
2) Use gdal_rasterize to burn the contour lines.
See http://gdal.org/gdal_rasterize.html
3) Fill the holes (the nodata values) with gdal_fillnodata.py.
See http://gdal.org/gdal_fillnodata.html
Now, the result should be usable with gdaldem.
well, yes, but it's likely to be pretty ugly -- it will represent the
elevation as steps -- constant values between contours. If you have
enough contour lines, and want a low-resolution DEM, that might be
OK. However, you'll get much prettier results if you interpolate in
some way to get a smoother result.
Unfortunately, interpolating contour lines well is not trivial -- I'd
do some googling and see what you can find.
GRASS may have something to help you here, too.
Chris,
gdal_fillnodata attempts to do interpolation and was designed with the
idea of filling in between contours and holes in elevation products. It
isn't perfect of course, but isn't the stepwise result you are expecting.
The algorithm effectively involves radial searches out from each pixel
to be interpolated, in 4 (or 8?) directions and then weighted distance
interpolation from the hits. It also does some user defined number of
iterations of post-interpolation smoothing to minimize artifacts.
Best regards,
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
