[gdal-dev] Converting contour lines (Shape files) into DEM

[Jan Hartmann]

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,