| 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 Order 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_3
derive 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 vaues 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. Height Grid Data Order
MKDSK can accept a variety of data orders. The order of data in the input file are described by keywords in the setup file. The input data can be 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. The assignment of the string 'YES' to the keyword
INPUT_GRID_ORDER_ROW_MAJORindicates that the data are in row-major order. The assignment of 'NO' indicates the data are in column-major order. The columns of the vertex grid can be filled in in top-down or bottom-up order. When top-down ordering is used, data within each vertex grid column are filled in in order of decreasing latitude or Y-value. This applies whether or not the input file has row-major order. If the order is not top-down, it is bottom-up. The assignment of the string 'YES' to the keyword
COLUMN_VALUE_ORDER_TOP_DOWNindicates that the data are in top-down order. The assignment of 'NO' indicates the data are in bottom-up order. The rows of the vertex grid can be filled in in left-to-right or right-to-left order. When left-to-right ordering is used, data within each vertex grid row are filled in in order of increasing longitude or X-value. This applies whether or not the input file has row-major order. If the order is not left-to-right, it is right-to-left. The assignment of the string 'YES' to the keyword
ROW_VALUE_ORDER_LEFT_RIGHTindicates that the data are in left-to-right order. The assignment of 'NO' indicates the data are in right-to-left order. The following examples show different possible orderings of the input height data. All orderings shown can be described by assignments in the setup file. For this example, we use an extremely small vertex grid having two rows and three columns. Let the vertices of the vertex grid be numbered as follows:
1 2 3
4 5 6
The orderings of the data for these vertices, as a function of the data
file's attributes, are shown below.
Row-major, top-down, left-right:
1 2 3
4 5 6
Row-major, top-down, right-left:
3 2 1
6 5 4
Row-major, bottom-up, left-right:
4 5 6
1 2 3
Row-major, bottom-up, right-left:
6 5 4
3 2 1
Column-major, top-down, left-right:
1 4
2 5
3 6
Column-major, top-down, right-left:
3 6
2 5
1 4
Column-major, bottom-up, left-right:
4 1
5 2
6 3
Column-major, bottom-up, right-left:
6 3
5 2
4 1
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.
A polar cap should not be generated if the input data set already has a row of vertices with latitude on that pole: the cap would contain degenerate plates. 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.
|