VDEMINT

Description

VDEMINT generates a raster digital elevation model (DEM) by interpolating elevation values of points, contours, and 3-D structure lines in vector segments. In addition, 2-D break lines, such as valleys, ridges, and cliffs with no elevation value are also accepted as constraints for interpolation.

Parameters

Name	Type	Length	Value range
Input: Input elevation values *	Vector port	1 - 1024
Output: Interpolated elevation layer *	Raster port	1 - 1
Pixel x-size (m)	Double	0 - 2
Pixel y-size (m)	Double	0 - 2
List of vector types	Integer	0 - 1024	0 - 7
Field name	String	0 - 1	Default: ATTRIBUTE
Maximum iterations	Integer	0 - 1	1 - 10 Default: 4
Working memory size (MB)	Integer	0 - 1	1 -

* Required parameter

Parameter descriptions

Input: Input elevation values

Specifies the vector segment or segments from which to interpolate the DEM.

All segments must be in the same file.

Output: Interpolated elevation layer

The output image channel to which to write the gridded DEM. When multiple files are processed, the same channel is used for each.

Pixel x-size (m)

Specifies the horizontal pixel size, in meters, for the projection of the output raster layer.

Pixel y-size (m)

Specifies the vertical pixel size, in meters, for the projection of the output raster layer.

List of vector types

Specifies the type of each vector segment selected for interpolation when creating a grid for the DEM.

The number of values specified for this parameter must be the same as the number of values in the input vector segments. A vector segment type specified for this parameter also applies to the vector segment at the same position in the list of input segments.

When no value is specified for this parameter, the module searches for segments named POINTS, CONTOURS, BREAKLIN, RIDGES, VALLEYS, CLIFFS, OUTLINE, and STRUCT3D, and automatically assigns the layer type based on each segment name.

The STRUCT3D layers are assumed to contain closed polygons representing vertically discontinuous structures, such as buildings, bridges, quarries, or sunken highways. Each polygon is interpolated inside its outline, but does not propagate elevations outside of the outline. The polygons can intersect other polygons. In the common area, the highest interpolated elevation is assigned to each pixel. The polygons can be also fully enclosed in other polygons. In such cases, the elevations of the interior polygons overwrite any other values within their outlines. If the layer contains points and lines, they are used for interpolation within the polygons that contain them. If only STRUCT3D layers are specified, all pixels outside polygon outlines are set to the background value.

Only one OUTLINE segment should be provided. If the selected OUTLINE segment has no shapes, the whole area is interpolated. Any number of segments of other types can be specified.

Field name

Specifies the name of the field that contains the elevation values.

If the value of this parameter is specified as ZCOORD, the actual z-coordinates of the vectors are used. Field names are not case-sensitive, and need not be specified in complete form. If more than one match exists, the first name is used.

This parameter is required only for vector layers that contain 3-D points or contours. With 3-D lines and 3-D polygons, the z-coordinates are used automatically. With 2-D layers, the elevation values are not specified.

The same name applies to all contour and 3-D point segments in the input vectors. Segments that do not satisfy this requirement can be converted to the required format by using ZVALTRNS.

When a field name other than ZCOORD is specified, but not found, VDEMINT attempts to use the z-coordinates of each vertex or point; this can, however, produce unexpected results.

Maximum iterations

Specifies the maximum number of iterations for smoothing the DEM, to a maximum of 10. Higher values produce smoother surfaces, but increase the processing time. The default value is 4; lower values such as 1 may work for points that are spaced closely, such as with LIDAR data. When multiple files are processed, the same number of iterations is used for each.

Working memory size (MB)

Specifies the amount of physical memory, in megabytes, to use for image buffers. The default is 25 percent of the total system memory.

When multiple files are processed, the same memory size is used for each.

More allocated memory usually results in faster processing. For more information about this parameter, see the Details section, later in this topic.

Details

VDEMINT generates a raster DEM by interpolating elevation values of points, contours, and 3-D structure lines in vector segments. In addition, 2-D break lines, such as valleys, ridges, and cliffs with no elevation value are also accepted as constraints for interpolation.

Typically, at least one of the 3-D points, contours and 3-D lines segments must be provided as an elevation source. The 2-D layers provide additional constraints for the interpolation of source elevations. In particular, a valley vector indicates a local minimum; a ridge vector indicates a local maximum; and a cliff vector indicates a discontinuity in the DEM. The 3-D structure polygons overwrite all other elevation values within their boundaries. If only 3-D structure polygons are specified, their elevations are interpolated within polygon outlines, but do not propagate outside polygon boundaries.

Other types of 3-D vector data, such as TIN networks, 3-D roads, 3-D rivers and valleys, and 3-D ridges must all be entered as 3-D lines.

The 3-D cliffs are undefined. If the elevation values on one or both sides of the cliff are known, they can be entered as another 3-D layer in addition to any 2-D cliff layers.

Only one OUTLINE segment should be provided. When multiple outline segments are specified or found, the first segment is used, and all others are ignored.

For the tags that do not exist, default values will be supplied, (0, 1), -32768, MSL and METER, respectively. When you specify an index file, the file must be in the format described in VDEMSETUP and ORTHO. In this case, the output files must not exist. They will be created by VDEMINT with parameters defined in the index file, including the preceding metadata tags. The output files will be created in the indicated folders if their names provide fully qualified (absolute) paths. Otherwise, each file name will be prepended with the full path of the index file before creation of the output file.

DEM pixel values stored in the output channel are transformed linearly according to the metadata tag ELEVATION_FACTOR values (offset and scale). They can be converted back to the elevation units specified by the ELEVATION_UNITS metadata tag through the following transformation:

        elevation_value = scale * (DEM_pixel_value + offset)
      

When no value is specified for the List of vector types (VECTYP) parameter, VDEMINT searches for segments named POINTS, CONTOURS, BREAKLIN, RIDGES, VALLEYS, CLIFFS, OUTLINE, and STRUCT3D, and uses all of the segments found for interpolation. In this case, the assigned layer type is based on the segment name. Only the first OUTLINE layer found is used.

When the OUTLINE layer is specified, it must contain a closed polygon or polygons surrounding the area or areas to interpolate. The polygons can have interior rings. When polygons are not closed properly, the results will be unpredictable. Pixels outside the polygons, including those under the polygon-boundary vectors, will be set to the value of the background elevation extracted from the NO_DATA_VALUE metadata tag of the elevation channel or the output file. If none of these values is specified, a value of -32768 will be used, and set as the metadata value of the output elevation channel.

When the STRUCT3D layers are specified, they are expected to contain closed polygons representing vertically discontinuous structures, such as buildings, bridges, quarries, or sunken highways. The 3-D polygons erase all other elevation data within their interiors, but do not propagate outside. Therefore, they usually produce vertical discontinuities just outside their perimeters. When the layers also contain lines and points, they are used during the interpolation of interior areas of the polygons containing them, but are overwritten at the polygon edges. When the polygons intersect, the highest interpolated elevation is used in the shared area. When a polygon fully encloses another, the elevation of the interior polygon is used within its area, regardless of whether it is lower or higher than the elevation of the exterior polygon.

Points or vertices with corrupted x, y, or z coordinates (not-a-number or +/- infinity) are not used in DEM interpolation.

The Working memory size (MB) (MEMSIZE) parameter specifies the amount of memory to use for image buffers. The buffer requirement for VDEMINT is 25 bytes per pixel without STRUCT3D layers, and 35 bytes per pixel with them. The memory is allocated statically for the duration of the run. At most, 16,383 megabytes of buffer memory will be allocated, plus the memory required for scanning of vector data.

VDEMINT attempts to divide the DEM area into tiles such that each tile can be processed in memory. Each tile has approximately the same size, and is extended by 256 pixels or lines on each side, so that there is overlap in input data used for interpolation of adjacent tiles. As a result, the whole DEM is generated faster, and there are no visible artifacts along tile boundaries, except in large areas void of input data.

VDEMINT must perform a pass over all input layers for each tile. Therefore, it is recommended that you allocate as much memory as possible, to minimize the number of tiles. A suitable limit is approximately 60 percent of your available system memory, unless you anticipate intensive use of the system by another process. Only the required memory is allocated: depending on the tile size, less memory may be used than the amount specified for the Working memory size (MB) (MEMSIZE) parameter.

When the individual layers do not cover the entire area of the DEM, their intersection with each tile is checked. When the layer has the "Extents" metadata tag, its content is used for the test, and this can significantly improve the speed of vector-layer scanning. Otherwise, the extents are derived internally, and used in all subsequent passes over the layers. Layers that do not intersect the current tile are skipped, which further increases the processing speed. Having the vector segments and the output DEM all in the same projection will also increase processing speed.

When the image cannot be tiled due to insufficient memory, it is processed as a single tile. In this case, VDEMINT uses image-buffer files. A small part of each processing buffer is kept in memory, and the rest is written to and read from a temporary file, as required. The results are the same as in the tiled case, but the heavy disk I/O significantly slows down generation of the DEM. The temporary files are creaed automatically by the module and deleted in the latter stages of processing.

VDEMINT processes the entire DEM. When large areas of the window are void of input data, the interpolated surface may show some artifacts, and may need to be edited manually. When the window contains multiple islands, and each is surrounded by a properly closed contour with the same elevation value, the no-data area will be filled with the same value. Similarly, the interior of a properly closed contour is filled with the constant elevation value of the contour, as long as there are no other 3-D data values inside the contour.

VDEMINT accepts incomplete vectors, such as open or crossed contours. When these values occur near a large, flat area, such as a body of water, they may "leak" into the area and must therefore be corrected to produce a consistent surface.

VDEMINT supports a mixture of vector and point data. It also supports dense point-only data sets with uniform point density. Data sets that have sparse points are better supported in PCI surface-interpolation tools.

Algorithm

The outline bitmap is created only when the footprint of the current file intersects one or more of the outline polygons. Output files fully outside of the outline polygons are filled with background values. Output files fully inside the outline polygons have all pixels filled with interpolated elevations.

During scan conversion, the input 3-D vector lines and points are reprojected to the raster coordinates, if necessary. They are then burned into the raster buffer with the elevations interpolated linearly between line vertices. At this stage, the 2-D and STRUCT3D layers are ignored. If multiple elevation values are scanned into a single pixel, the minimum-elevation value is assigned to the pixel, the maximum elevation is recorded for use in interpolation, and the pixel is marked as a cliff.

In the second step, the elevation value in each DEM pixel is interpolated from the source elevation data. The process uses the pyramid-interpolation algorithm. For more information on the algorithm, follow the link to PYRINT under Related functions at the end of this topic.

The algorithm is adapted to recognize multivalued pixels and cliffs, and to retain the discontinuity between their 'low' and 'high' sides. The pyramid-interpolation algorithm retains all source and background elevation values, and acts as a smoothing filter for the interpolated values.

In the optional step, any 2-D vector layers present are scanned. Their neighborhood is erased, and then interpolated on condition that the 2-D feature retains its locally extremal value.

The default number of iterations is suitable for most circumstances. For data consisting mostly of densely spaced points, such as LIDAR data sets, the number of iterations may be lowered to one.

During scanning of the STRUCT3D layers, any non-polygon data is scanned first, and then each polygon is scanned and interpolated individually, starting with the largest. The interpolated values then overwrite the non-STRUCT3D data within the STRUCT3D polygon outlines.

The current processing tile is written to the output file, and the process continues for subsequent tiles.

After completion of the current output file, the code loops over subsequent files, if required. Please note that the progress status, when enabled, indicates the percent of completion for each individual file. An additional message indicates which output file, and of how many, is being processed currently.