MKDSK User's Guide |
Table of ContentsMKDSK User's Guide Abstract Summary References Usage Running MKDSK MKDSK Setup File Setup File Format Setup File Assignments Required Assignments Conditional Assignments Optional Assignments Detailed Description of Setup File Keywords Setup File Examples Input Using Latitudinal Coordinates and Plate Type 2 Input Using Planetodetic Coordinates and Plate Type 1 Input Using Planetocentric Coordinates and Plate Type 5 Input Data File Units Reference Frame Vertex order Vertex IDs Plate Data File Type 1 (Plate-Vertex Table) Sample Plate-Vertex Table Input File Plate Data File Type 2 (Gaskell Shape Model) Sample Gaskell Shape Model Input File Plate Data File Type 3 (Vertex-Facet Table) Sample Vertex-Facet Input File Rosetta/OSIRIS ``ver'' File Sample Rosetta/OSIRIS ``ver'' File ASCII Height Grid File Domain Coordinates Heights Height Grid File Format Height Grid Data Mapping Polar Caps Longitude Wrapping Output DSK File Appendix A: Spatial Index and Voxels MKDSK User's Guide
Abstract
Summary
The MKDSK program requires as input a setup file containing input parameters and a second file containing the shape data to be processed. Data files provided to this program either represent an object's surface as a collection of triangular plates, or as a height grid. Currently the only supported output DSK data type is type 2: this type represents the surface of a specified body as a collection of triangular plates. The program allows the user to optionally specify some descriptive text in a separate file, called the ``comment file,'' to be placed into the ``comment area'' of the DSK file. (Doing this is highly recommended.) For archival documentation purposes the content of the MKDSK setup file is automatically placed at the end of the ``comment area'' of the DSK file. References
https://naif.jpl.nasa.gov/naif/tutorials.html Usage
mkdsk -u Program usage: > mkdsk [-setup <setup file name>] [-input <input shape data file name>] [-output <output DSK file name>] [-h|-help] [-t|-template] [-u|-usage] [-v|-version]If a setup file name isn't provided on the command line, MKDSK will prompt for it. It will not prompt for the input or output file names; these file names must be provided on the command line or in the setup file. If the input or output file names are provided on the command line, any corresponding file names assigned using setup keywords are ignored. The input file must already exist and the output file must be a new file. Running MKDSK
As the program runs, it will print out messages describing its progress. If an error is encountered, the program normally will display a diagnostic message. The program attempts to delete the output file if it encounters an error while creating it. Only one DSK file containing one segment may be generated during a single MKDSK run. MKDSK Setup FileSetup File Format
The format of this file must conform to the SPICE text kernel specification. This format uses a ``keyword = value'' syntax for assignment of parameter values. The Kernel Required Reading document, which is included in the SPICE Toolkit, provides details of this format specification. The ``Intro to Kernels'' tutorial, which is available on the NAIF web site
http://naif.jpl.nasa.gov/naif/tutorials.htmlmay also be helpful. Examples of setup files are included in this document. Often the easiest way to create a setup file for your own use is to modify an existing example. For quick reference, a few details concerning the SPICE text kernel format are listed below: The names of the setup file keywords must be strictly uppercase while parameterized keyword values (for example 'DEGREES'), reference frame names, and body names may be upper, lower or mixed case. File names should be assumed to be case sensitive to maximize portability. Any white space preceding or following keyword names, values and the equal sign is ignored. All character string values and time strings must be enclosed in single quotes. They must be provided on a single line or continued with the '+' character as the final character of the value. The portion of the string value on a single line can be no longer than 80 characters. When multiple values are allowed and used, enclose the complete set in the "()" characters: KEYWORD = ( 'value1' 'value2' ... ). Setup File Assignments
A setup file may contain blank lines. Non-printing characters including TAB should not be used in setup file lines containing keyword assignments or in blank lines separating assignment lines within the data sections of a setup file. The program may not be able to parse correctly any of the setup file lines that contain non-printing characters and will signal a setup file parsing error on some computer platforms. Required Assignments
SURFACE_NAME = 'Surface name' (name of the specific shape data set for the central body) An ID code may be specified as a single-quoted string. CENTER_NAME = 'Central body name'. An ID code may be specified as a single-quoted string. REF_FRAME_NAME = 'Reference frame name' START_TIME = 'Start time' STOP_TIME = 'Stop time' DATA_CLASS = 1 to indicate a surface that can be represented as a single-valued function of its domain coordinates. 2 indicates a general surface. Surfaces that have multiple points for a given pair of domain coordinates---for example, multiple radii for a given latitude and longitude---belong to class 2. INPUT_DATA_UNITS = ( 'ANGLES = angular unit' 'DISTANCES = distance unit' ) COORDINATE_SYSTEM = 'LATITUDINAL' or 'RECTANGULAR' or 'PLANETODETIC' DATA_TYPE = 2 (triangular plates) This is the data type of the single segment in the output file created by this program. Currently only type 2 is supported. PLATE_TYPE = an integer in the range 1:5 specifying the input data file format. This assignment is applicable only to output data type 2. See the chapter ``Input Data File'' for further information.The following assignments are required in the setup file if their values are not provided on the command line:
INPUT_SHAPE_FILE = 'Name of input shape data file' OUTPUT_DSK_FILE = 'Name of output DSK file ' Conditional Assignments
KERNELS_TO_LOAD = ( 'kernel_1' 'kernel_2' ... ) Leapseconds kernel (if not specified by the LEAPSECONDS_KERNEL assignment) and names of additional kernels, for example frame kernels to provide body-fixed frame specifications. LEAPSECONDS_KERNEL = 'file name' A leapseconds kernel must be specified using either this assignment or using a KERNELS_TO_LOAD assignment. NAIF_BODY_NAME += 'body name' NAIF_BODY_CODE += integer ID code These assignments are needed if the central body name is not built into SPICE and its body name-ID association is not defined in a kernel listed in a KERNELS_TO_LOAD assignment. NAIF_SURFACE_NAME += 'surface name' NAIF_SURFACE_CODE += integer surface ID code NAIF_SURFACE_BODY += integer body ID code These assignments are needed if the surface name-ID association is not defined in a kernel listed in a KERNELS_TO_LOAD assignment. For latitudinal coordinates: MINIMUM_LATITUDE = lower latitude bound in selected angular units MAXIMUM_LATITUDE = upper latitude bound in selected angular units MINIMUM_LONGITUDE = lower longitude bound in selected angular units MAXIMUM_LONGITUDE = upper longitude bound in selected angular units For rectangular coordinates: MINIMUM_X = lower X coordinate bound in selected units MAXIMUM_X = upper X coordinate bound in selected units MINIMUM_Y = lower Y coordinate bound in selected units MAXIMUM_Y = upper Y coordinate bound in selected units For planetodetic coordinates: MINIMUM_LATITUDE = lower latitude bound in selected units MAXIMUM_LATITUDE = upper latitude bound in selected units MINIMUM_LONGITUDE = lower longitude bound in selected units MAXIMUM_LONGITUDE = upper longitude bound in selected units EQUATORIAL_RADIUS = equatorial spheroid radius in selected units POLAR_RADIUS = polar spheroid radius in selected units For data type 2, plate type 5, the following additional assignments are required: WRAP_LONGITUDE = connect leftmost column to rightmost column: 'YES' or 'NO' MAKE_NORTH_POLAR_CAP = extend plate set to north pole: 'YES' or 'NO' MAKE_SOUTH_POLAR_CAP = extend plate set to south pole: 'YES' or 'NO' INPUT_GRID_ORDER_ROW_MAJOR = input data set is row-major: 'YES' or 'NO' COLUMN_VALUE_ORDER_TOP_DOWN = input data set is top-down: 'YES' or 'NO' ROW_VALUE_ORDER_LEFT_RIGHT = input data set is left-right: 'YES' or 'NO' NUMBER_OF_ROWS = number of rows in grid NUMBER_OF_COLUMNS = number of columns in grid COLUMN_STEP_SIZE = column separation: longitude or X step ROW_STEP_SIZE = row separation: latitude or Y step HEIGHT_SCALE = value by which to multiply the height data to convert to km For data type 2, plate type 5, latitudinal or rectangular coordinates, the following additional assignment is required: HEIGHT_REFERENCE = value to add to input heights; units are always km For data type 2, plate type 5, rectangular coordinates, the following additional assignments are required: LEFT_COLUMN_X_COORDINATE = X-coordinate of leftmost column of grid TOP_ROW_Y_COORDINATE = Y-coordinate of top row of grid For data type 2, plate type 5, latitudinal or planetodetic coordinates, the following additional assignments are required: LEFT_COLUMN_LONGITUDE = longitude of leftmost column of grid TOP_ROW_LATITUDE = latitude of top row of grid Optional Assignments
COMMENT_FILE = 'Name of optional comment file' FINE_VOXEL_SCALE = Double precision value > 0.0 COARSE_VOXEL_SCALE = Integer >= 1 Optional assignment: MAKE_VERTEX_PLATE_MAP = 'YES' or 'NO' If this assignment is not provided, MKDSK will not create a vertex-plate mapping. Detailed Description of Setup File Keywords
Setup File ExamplesInput Using Latitudinal Coordinates and Plate Type 2
\begindata INPUT_SHAPE_FILE = 'phobos_q512.txt' OUTPUT_DSK_FILE = 'phobos512.bds' COMMENT_FILE = ' ' KERNELS_TO_LOAD = ( 'naif0012.tls' ) SURFACE_NAME = 'Gaskell Phobos Q=512' CENTER_NAME = 'PHOBOS' REF_FRAME_NAME = 'IAU_PHOBOS' START_TIME = '1950-JAN-1/00:00:00' STOP_TIME = '2050-JAN-1/00:00:00' DATA_CLASS = 1 INPUT_DATA_UNITS = ( 'ANGLES = DEGREES' 'DISTANCES = KILOMETERS' ) COORDINATE_SYSTEM = 'LATITUDINAL' MINIMUM_LATITUDE = -90.0 MAXIMUM_LATITUDE = 90.0 MINIMUM_LONGITUDE = -180.0 MAXIMUM_LONGITUDE = 180.0 DATA_TYPE = 2 PLATE_TYPE = 2 NAIF_SURFACE_NAME += 'Gaskell Phobos Q=512' NAIF_SURFACE_CODE += 1 NAIF_SURFACE_BODY += 401 \begintext Input Using Planetodetic Coordinates and Plate Type 1
megr90n000cbThis data set has a resolution of 4 pixels/degree. The surface coverage is global. This example presumes that vertices and plates have already been derived from original input data, which constitute a digital elevation model (DEM).
\begindata INPUT_SHAPE_FILE = 'megr90n000cb.inp' OUTPUT_DSK_FILE = 'megr90n000cb_1.bds' COMMENT_FILE = ' ' KERNELS_TO_LOAD = ( 'naif0012.tls' ) SURFACE_NAME = 'megr90n000cb --- plates' CENTER_NAME = 'MARS' REF_FRAME_NAME = 'IAU_MARS' START_TIME = '1950-JAN-1/00:00:00' STOP_TIME = '2050-JAN-1/00:00:00' DATA_CLASS = 1 INPUT_DATA_UNITS = ( 'ANGLES = DEGREES' 'DISTANCES = KILOMETERS' ) COORDINATE_SYSTEM = 'PLANETODETIC' EQUATORIAL_RADIUS = 3396.19 POLAR_RADIUS = 3376.20 MINIMUM_LATITUDE = -90.0 MAXIMUM_LATITUDE = 90.0 MINIMUM_LONGITUDE = -180.0 MAXIMUM_LONGITUDE = 180.0 DATA_TYPE = 2 PLATE_TYPE = 1 NAIF_SURFACE_NAME += 'megr90n000cb --- plates' NAIF_SURFACE_CODE += 1 NAIF_SURFACE_BODY += 499 \begintext Input Using Planetocentric Coordinates and Plate Type 5
We give this surface a distinct name from that of the previous example, since the plate set created from the input data will differ. The input data file is organized in row-major, top-down, left-to-right order. The top and bottom input pixel centers are 1/2 pixel away from the poles, so we add polar caps. Similarly, the pixel centers of leftmost and rightmost columns are one pixel apart, so we invoke longitude wrapping. These choices create a plate set with complete coverage. The distance units are meters.
\begindata INPUT_SHAPE_FILE = 'megr90n000cb.inp' OUTPUT_DSK_FILE = 'megr90n000cb_2.bds' COMMENT_FILE = ' ' KERNELS_TO_LOAD = ( 'naif0012.tls' ) SURFACE_NAME = 'megr90n000cb --- grid' CENTER_NAME = 'MARS' REF_FRAME_NAME = 'IAU_MARS' START_TIME = '1950-JAN-1/00:00:00' STOP_TIME = '2050-JAN-1/00:00:00' DATA_CLASS = 1 INPUT_DATA_UNITS = ( 'ANGLES = DEGREES' 'DISTANCES = METERS' ) COORDINATE_SYSTEM = 'LATITUDINAL' NUMBER_OF_ROWS = 720 NUMBER_OF_COLUMNS = 1440 ROW_STEP_SIZE = 0.25 COLUMN_STEP_SIZE = 0.25 LEFT_COLUMN_LONGITUDE = -180.0 TOP_ROW_LATITUDE = 89.875 INPUT_GRID_ORDER_ROW_MAJOR = 'YES' COLUMN_VALUE_ORDER_TOP_DOWN = 'YES' ROW_VALUE_ORDER_LEFT_RIGHT = 'YES' WRAP_LONGITUDE = 'YES' MAKE_NORTH_POLAR_CAP = 'YES' MAKE_SOUTH_POLAR_CAP = 'YES' HEIGHT_SCALE = 1.D-3 HEIGHT_REFERENCE = 3396000 MINIMUM_LATITUDE = -90.0 MAXIMUM_LATITUDE = 90.0 MINIMUM_LONGITUDE = -180.0 MAXIMUM_LONGITUDE = 180.0 DATA_TYPE = 2 PLATE_TYPE = 5 NAIF_SURFACE_NAME += 'megr90n000cb --- grid' NAIF_SURFACE_CODE += 2 NAIF_SURFACE_BODY += 499 \begintext Input Data File
The type 2 segment design has no restrictions on sizes or configuration of the triangular plates defined by the vertices, even within a single plate model file. Indeed it is quite normal that the plate sizes and local plate density vary across the model in order to achieve desired shape fidelity without using an excessive number of plates. It is recommended that the input data not define any degenerate plates (plates having zero-length edges). Such plates may cause run-time failures of computations that require each plate to have a computable outward normal vector. MKDSK reads an ASCII text file containing body shape data. This text file must conform to one of the following formats:
Units
Reference Frame
Vertex order
plate = vertex_1, vertex_2, vertex_3derive the outward normal as:
- -------- -------- -------- -------- n = ( vertex_2 - vertex_1) X (vertex_3 - vertex_2) Vertex IDs
Plate Data File Type 1 (Plate-Vertex Table)
N 1 X(1) Y(1) Z(1) 2 X(2) Y(2) Z(2) ... N X(N) Y(N) Z(N) M 1 V1(1) V2(1) V3(1) 2 V1(2) V2(2) V3(2) ... M V1(M) V2(M) V3(M)where
Sample Plate-Vertex Table Input File
12 1 0. 0. 1.17557 2 0.32492 1. 0.525731 3 1.05146 0. 0.525731 4 -0.850651 0.618034 0.525731 5 -0.850651 -0.618034 0.525731 6 0.32492 -1. 0.525731 7 0.850651 0.618034 -0.525731 8 -0.32492 1. -0.525731 9 -1.05146 0. -0.525731 10 -0.32492 -1. -0.525731 11 0.850651 -0.618034 -0.525731 12 0. 0. -1.17557 20 1 1 3 2 2 1 2 4 3 1 4 5 4 1 5 6 5 1 6 3 6 3 7 2 7 2 8 4 8 4 9 5 9 5 10 6 10 6 11 3 11 7 8 2 12 8 9 4 13 9 10 5 14 10 11 6 15 11 7 3 16 7 12 8 17 8 12 9 18 9 12 10 19 10 12 11 20 11 12 7 Plate Data File Type 2 (Gaskell Shape Model)
The data file has the form:
Q X(1) Y(1) Z(1) X(2) Y(2) Z(2) ... ... ... X(6*(Q+1)^2) Y(6*(Q+1)^2) Z(6*(Q+1)^2)where
6 * (Q+1)^2
Sample Gaskell Shape Model Input File
64 -9.36329 3.76796 3.80970 -9.12138 3.82357 3.86143 -8.87987 3.88047 3.91416 -8.63347 3.92422 3.95698 -8.39016 3.97415 4.00291 -8.14081 4.03950 4.05743 -7.88861 4.08816 4.09352 -7.63058 4.07331 4.08113 -7.37114 4.03909 4.05807 -7.11810 4.05018 4.08515 -6.89451 4.12730 4.15128 -6.69135 4.24326 4.25130 -6.46167 4.30681 4.31349 ... ... ... Plate Data File Type 3 (Vertex-Facet Table)
v X(1) Y(1) Z(1) v X(2) Y(2) Z(2) ... v X(N) Y(N) Z(N) f V1(1) V2(1) V3(1) f V1(2) V2(2) V3(2) ... f V1(M) V2(M) V3(M)where
Sample Vertex-Facet Input File
v 0. 0. 1.17557 v 0.32492 1. 0.525731 v 1.05146 0. 0.525731 v -0.850651 0.618034 0.525731 v -0.850651 -0.618034 0.525731 v 0.32492 -1. 0.525731 v 0.850651 0.618034 -0.525731 v -0.32492 1. -0.525731 v -1.05146 0. -0.525731 v -0.32492 -1. -0.525731 v 0.850651 -0.618034 -0.525731 v 0. 0. -1.17557 f 1 3 2 f 1 2 4 f 1 4 5 f 1 5 6 f 1 6 3 f 3 7 2 f 2 8 4 f 4 9 5 f 5 10 6 f 6 11 3 f 7 8 2 f 8 9 4 f 9 10 5 f 10 11 6 f 11 7 3 f 7 12 8 f 8 12 9 f 9 12 10 f 10 12 11 f 11 12 7 Rosetta/OSIRIS ``ver'' File
Sample Rosetta/OSIRIS ``ver'' File
12 20 0. 0. 1.17557 0.32492 1. 0.525731 1.05146 0. 0.525731 -0.850651 0.618034 0.525731 -0.850651 -0.618034 0.525731 0.32492 -1. 0.525731 0.850651 0.618034 -0.525731 -0.32492 1. -0.525731 -1.05146 0. -0.525731 -0.32492 -1. -0.525731 0.850651 -0.618034 -0.525731 0. 0. -1.17557 3 1 3 2 3 1 2 4 3 1 4 5 3 1 5 6 3 1 6 3 3 3 7 2 3 2 8 4 3 4 9 5 3 5 10 6 3 6 11 3 3 7 8 2 3 8 9 4 3 9 10 5 3 10 11 6 3 11 7 3 3 7 12 8 3 8 12 9 3 9 12 10 3 10 12 11 3 11 12 7 ASCII Height Grid File
Each group of four adjacent vertices in the grid defines a pair of plates as shown below:
vertex(I,J) vertex(I,J+1) +----------------+ |\ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \| +----------------+ vertex(I+1,J) vertex(I+1,J+1) Domain Coordinates
The size of the grid is given by a row count NROWS and a column count NCOLS; these are the values assigned by the setup file to the keywords NUMBER_OF_ROWS and NUMBER_OF_COLUMNS. The domain coordinates of the grid are defined by starting values and constant step values. For planetocentric latitudinal and planetodetic coordinates, longitudes are defined by a ``leftmost'' (minimum) longitude LFTLON and a longitude step size LONSTP. These are the values assigned to the keywords LEFT_COLUMN_LONGITUDE and COLUMN_STEP_SIZE. The longitudes of the grid points increase from
LFTLON to LFTLON + ((NCOLS-1) * LONSTP)Latitudes are defined by a top (maximum) latitude TOPLAT and a latitude step size LATSTP. These are the values assigned to the keywords TOP_ROW_LATITUDE and ROW_STEP_SIZE. The latitudes of the grid points decrease from
TOPLAT to TOPLAT - ((NROWS-1) * LATSTP)For rectangular coordinates, X values are defined by a ``leftmost'' (minimum) X value LEFTX and an X step size XSTEP. These are the values assigned to the keywords LEFT_COLUMN_X and COLUMN_STEP_SIZE. The X values of the grid points increase from
LEFTX to LEFTX + ((NCOLS-1) * XSTEP)Y values are defined by a top (maximum) Y value TOPY and a Y step size YSTEP. These are the values assigned to the keywords TOP_ROW_Y and ROW_STEP_SIZE. The Y values of the grid points decrease from
TOPY to TOPY - ((NROWS-1) * YSTEP) Heights
HEIGHT_SCALEThis scale is a factor by which the input heights are to be multiplied to convert them to km. For planetodetic coordinates, heights are expressed relative to the reference spheroid of the coordinate system. The equatorial and polar radii of this spheroid are provided as setup file inputs. For planetocentric latitudinal and rectangular coordinates, input heights are expressed relative to a reference height value which is supplied in the setup file; the keyword for this value is HEIGHT_REFERENCE. Units of the reference height are always km. Height Grid File Format
The data values must be separated by blanks or commas. There are no restrictions on the precision of the data values. The count of data values per line need not be constant. However, the file may be easier to human readers to scan if data values are placed in fixed-width columns. MKDSK reads the input height data file sequentially: it views the values in a height grid file as a 1-dimensional stream of data. Values in lines are read from the file from left to right; lines are read from the start of the file to the end. Height Grid Data Mapping
The input data can be arranged in either row-major or column-major order. Row-major order means that data for rows in the vertex grid are adjacent in the input file: the first NCOLS elements of the file belong to a row, the next NCOLS elements belong to a row, and so on. Column-major order means that data for columns in the vertex grid are adjacent in the input file: the first NROWS elements of the file belong to a column, the next NROWS elements belong to a column, and so on. Input data can be mapped to the vertex grid in top-down or bottom-up order, and in left-to-right or right-to-left order. The possible mappings are illustrated below. Setup file keywords controlling the mapping are discussed following these diagrams. When the input data are arranged in row-major order, rows of height data in the input file map to rows in the segment's vertex grid as shown below. Entries of the form h_ij represent height values in the ith row and jth column of the input file. Horizontal and vertical lines denote additional rows and columns of data. If the input data organization is row-major, top-down and left-right, the mapping is:
h_11 h_12 ... h_1n h_11 h_12 ... h_1n h_21 h_22 ... h_2n h_21 h_22 ... h_2n --------------------- --------------------- ... -> ... --------------------- --------------------- --------------------- --------------------- Input file Segment's vertex gridIf the input data organization is row-major, top-down and right-left, the mapping is:
h_11 h_12 ... h_1n h_1n ... h_12 h_11 h_21 h_22 ... h_2n h_2n ... h_22 h_21 --------------------- --------------------- ... -> ... --------------------- --------------------- --------------------- --------------------- Input file Segment's vertex gridIf the input data organization is row-major, bottom-up and left-right, the mapping is:
h_11 h_12 ... h_1n --------------------- h_21 h_22 ... h_2n --------------------- --------------------- ... ... -> --------------------- --------------------- h_21 h_22 ... h_2n --------------------- h_11 h_12 ... h_1n Input file Segment's vertex gridIf the input data organization is row-major, bottom-up and right-left, the mapping is:
h_11 h_12 ... h_1n --------------------- h_21 h_22 ... h_2n --------------------- --------------------- ... ... -> --------------------- --------------------- h_2n ... h_22 h_21 --------------------- h_1n ... h_12 h_11 Input file Segment's vertex gridWhen the input data are arranged in column-major order, rows of height data in the input file map to columns in the segment's vertex grid as shown below. If the input data organization is column-major, top-down and left-right, the mapping is:
h_11 h_12 ... h_1n h_11 h_21 | | | h_21 h_22 ... h_2n h_12 h_22 | | | --------------------- | | | ... -> ... ... | ... | | --------------------- | | | --------------------- h_1n h_2n | | | Input file Segment's vertex gridIf the input data organization is column-major, top-down and right-left, the mapping is:
h_11 h_12 ... h_1n | | | h_21 h_11 h_21 h_22 ... h_2n | | | h_22 h_12 --------------------- | | | ... -> | | ... | ... ... --------------------- | | | --------------------- | | | h_2n h_1n Input file Segment's vertex gridIf the input data organization is column-major, bottom-up and left-right, the mapping is:
h_11 h_12 ... h_1n h_1n h_2n | | | h_21 h_22 ... h_2n | | | --------------------- ... ... | ... | | ... -> | | | --------------------- h_12 h_22 | | | --------------------- h_11 h_21 | | | Input file Segment's vertex gridIf the input data organization is column-major, bottom-up and right-left, the mapping is:
h_11 h_12 ... h_1n | | | h_2n h_1n h_21 h_22 ... h_2n | | | --------------------- | | ... | ... ... ... -> | | | --------------------- | | | h_22 h_12 --------------------- | | | h_21 h_11 Input file Segment's vertex gridThe assignment of the string 'YES' to the keyword
INPUT_GRID_ORDER_ROW_MAJORindicates that the input height data are arranged in row-major order. The assignment of 'NO' indicates the data are in column-major order. The assignment of the string 'YES' to the keyword
COLUMN_VALUE_ORDER_TOP_DOWNindicates that the input height data are to be mapped to the vertex grid in top-down order. The assignment of 'NO' indicates the mapping is bottom-up. The assignment of the string 'YES' to the keyword
ROW_VALUE_ORDER_LEFT_RIGHTindicates that the input height data are to be mapped to the vertex grid in left-to-right order. The assignment of 'NO' indicates the mapping is right-to-left. Polar Caps
A polar cap is created by placing an artificial vertex on the positive or negative Z axis, as specified. The height of the vertex is derived by taking the average of the heights from the adjacent row of the vertex grid. Plates are formed using the polar vertex and vertices of the adjacent row of vertices. If longitude wrapping is enabled, a plate is created that covers the region between the specified pole and that filled in by longitude wrapping. North and south polar caps can be created independently. The assignment of the string 'YES' to either of the keywords
MAKE_NORTH_POLAR_CAP MAKE_SOUTH_POLAR_CAPenables creation of the specified polar caps. Plates created for the north polar cap have the following form:
north polar vertex + |\ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ +----------------+ vertex(1,J) vertex(1,J+1)Plates created for the south polar cap are like the above, but include vertices of the southernmost row of the grid, and are inverted in the direction of latitude. If the input data set has a row of vertices with latitude on a pole, that row is converted to single vertex having height equal to the average height of the original vertices, and a polar cap is created using that vertex and the adjacent row of vertices. As a result, no degenerate plates are created. MKDSK takes these actions regardless of whether creation of polar caps is commanded. Longitude Wrapping
WRAP_LONGITUDEenables longitude wrapping. Plates created by longitude wrapping have the following form:
vertex(I,NCOLS) vertex(I,1) +----------------+ |\ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \ | | \| +----------------+ vertex(I+1,NCOLS) vertex(I+1,1)The plate created by longitude wrapping for the north polar cap has the form:
north polar vertex + |\ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ | \ +----------------+ vertex(1,NCOLS) vertex(1,1)The plate created by longitude wrapping for the south polar cap is like the above, but includes vertices of the southernmost row of the grid, and is inverted in the direction of latitude. Longitude wrapping should not be used if the input data set already has the rightmost column overlapping the leftmost column. The new plates would either be degenerate or inward-facing. Output DSK File
The output file is not human-readable: it is a binary file designed to support rapid read access by SPICE software and SPICE-based applications. The contents of the output file can be summarized by running the SPICE utility program DSKBRIEF. It is recommended that DSK creators use DSKBRIEF to verify that the output file has the intended attributes. Data may be extracted from the output DSK file using the interface software provided in the SPICE library. Data also may be exported from the DSK file to a human-readable text file by means of the SPICE utility program DSKEXP. Appendix A: Spatial Index and Voxels
``Voxel scales'' are attributes of a data structure in type 2 DSK segments called a ``spatial index.'' The spatial index enables type 2 DSK software to rapidly locate plates in a given region of space. Starting with the release of the N0066 SPICE Toolkit, MKDSK automatically computes voxel scales appropriate for the input data. In some cases, speed of ray-surface intercept computations can be improved by manually adjusting the voxel scales. See the DSK Required Reading [1] for a detailed description of DSK type 2 spatial indexes.
|