MRT Manual
MRT Manual
MRT Manual
USERS MANUAL
Release 4.1
April 2011
Land Processes DAAC
USGS Earth Resources Observation and Science (EROS) Center
April 2011
Table of Contents
Introduction.................................................................................................................................................4
MODIS Reprojection Tool Capabilities.......................................................................................................5
Platforms
5
Interfaces
5
Data Products
5
File Formats 5
Data Types 6
Map Projections
6
Resampling 6
Format Conversion 6
Mosaic Tool 7
Datum Conversions 7
Spectral subsetting 8
Spatial subsetting
8
Output Pixel Size
9
Parameter Files
9
Metadata
9
Background Fill
10
Corner Coordinates 10
Log File
10
Bounding Tiles
10
Bounding Tile Issue
Bounding Tile Solution
11
13
17
20
37
MRT Users Manual
April 2011
39
52
Credits.......................................................................................................................................................56
Contacts.....................................................................................................................................................56
Appendix A: MRT Parameter File Format.................................................................................................57
File naming conventions
Editing parameter files
Parameter file format 57
57
57
61
65
66
April 2011
Introduction
The Moderate Resolution Imaging Spectroradiometer (MODIS) was launched into space aboard the
National Aeronautics and Spaces Administration (NASA) Earth Observing System (EOS) platform Terra
in December 1999. A second MODIS sensor was launched on the Aqua platform in May 2002. The
objective of MODIS is to provide a comprehensive series of global observations of Earths land, oceans,
and atmosphere at higher spatial resolutions (250-meter (m), 500-m, 1,000-m) than its predecessor, the
Advanced Very High Resolution Radiometer (AVHRR), and more frequently (near-daily overpass) than
its orbital neighbor Landsat 71. MODIS observations are critical for studies of climate, vegetation,
pollution, global change, and many other important economic and environmental issues.
The MODIS Reprojection Tool (MRT) was developed to support higher level MODIS Land products
which are distributed as Hierarchical Data Format-Earth Observing System (HDF-EOS) 2 files projected to
a tile-based Sinusoidal grid. MRT software facilitates the use of MODIS Land tiles by providing map
projection, format conversion, and spectral and spatial subsetting options and is compiled for use on
multiple operating systems.
MRT functionality is based on the resample and mrtmosaic executables that may be run either from
the command line or from a Graphical User Interface (GUI). The GUI is an easy, user-friendly way to
input data for manipulation, and the more powerful command line interface serves users with intensive
data processing requirements. This Users Manual describes the use of both to run the MRT resample
and mrtmosaic programs.
April 2011
Though they were not tested, MRT is expected to install and run on other systems (such as
Windows Vista and Windows 7). Consult the Release Notes for platform-specific differences and
caveats.
Interfaces
MRT may be invoked either from a user-friendly GUI or from a powerful command-line interface. The
GUI allows novices and users with light processing requirements to reproject, convert, and subset
MODIS tiled data. The GUI also allows easy inspection of metadata. The scriptable command-line
interface, with its variety of command-line options, is likely to be the method of choice for reprojecting
large numbers of files.
Data Products
MRT currently allows reprojection of all gridded (levels-2G, 3, and 4) MODIS Land data products.
Support for swath (levels-1B and 2) data is available in the MRTSwath application 3.
Most MODIS products are 2-Dimensional (2-D), but there are some 3-D and 4-D data sets (e.g., the
MCD43 BRDF-Albedo suite4). The MRT supports 3-D and 4-D data products and currently outputs them
to 2-D data products for raw binary, georeferenced tagged image file format (GeoTIFF), and HDF-EOS
output formats.
File Formats
April 2011
MRT accepts raw binary or tiled MODIS Land products in HDF-EOS format as input. Output file formats
include raw binary, HDF-EOS, and GeoTIFF. The raw binary file format is specified in Appendix B.
Data Types
MRT supports 8-bit, 16-bit, and 32-bit integer data (both signed and unsigned), as well as 32-bit float
data. The output data type is always the same as the input data type.
Map Projections
MRT uses calls to the General Cartographic Transformation Package (GCTP) 5 and as such allows
projection to the following mapping grids.
The GCTP used by MRT applications has been modified to incorporate the Integerized Sinusoidal
Projection originally applied to Version 001 MODIS products.
Resampling
Three resampling methods are available in MRT: nearest neighbor ( NN), bilinear (BIL), and cubic
convolution (CC).
Format Conversion
April 2011
MRT provides an option to convert an input file to a different format without reprojecting. The possible
input and output formats are described in File Formats above. The Format Converter will support spectral
and spatial subsetting. When doing format conversion, the resampling process will be skipped. The output
projection type and output projection parameters are not needed, and will be ignored if specified. In
format conversion the output projection type is the same as the input projection type, and the output
projection parameters are the same as the input projection parameters. The output pixel size (if specified
will be ignored) remains the same as the input pixel size, as does the output data type.
NOTE: A simple command-line tool (called hdf2rb) is used for format conversion from HDF to raw
binary. It does not rely on geographic information and therefore works well with bounding tiles.
Mosaic Tool
MRT can mosaic several tiles together before reprojecting them. Mosaicking is done automatically from
the GUI by selecting several filenames for the input filename. The input files are mosaicked first, and
then reprojected. Mosaicking can also be done via the command line using the mrtmosaic executable.
Datum Conversions
A limited number of input and output datums are supported by the MRT for datum conversions.
Supported datums are North American Datums of 1927 ( NAD27), and 1983 (NAD83), and World Geodetic
Systems of 1966 (WGS66), 1972 (WGS72), and 1984 (WGS84). User specification of the output datum is
supported as part of the output parameters for the MRT in both the GUI and command-line interfaces. The
GUI uses a datum drop-down box to allow the datum to be specified. This drop-down box has NODATUM
set as the default, with options to select available datums. If the command-line version is being used, then
the datum should be specified using the DATUM parameter in the parameter file, entering either any of the
datums listed above or NODATUM. If no value is provided for the DATUM in the parameter file, NODATUM
will be used as the default.
A datum is a standard definition of the semi-major and semi-minor axes of a shape. If the NODATUM
option is selected, MRT will expect the user to enter spheroid information in the first two fields of the
projection parameters for all the MRT-supported projections except UTM and Geographic. If the semimajor and semi-minor axes are not specified while the NODATUM is selected, MRT will exit with an error.
Likewise, if semi-major and semi-minor axes are entered in the projection parameters and a specific
datum is selected, the MRT will exit with an error.
April 2011
Please note that the current GCTP package automatically uses the radius of Sphere 19 (6370997-m) for
any sphere-based projections, except for Sinusoidal and Integerized Sinusoidal. Until this is fixed in
GCTP, if the user needs to specify a radius other than that used for Sphere 19, the NODATUM option must
be used. For Integerized Sinusoidal and Sinusoidal projections, users are allowed to specify their own
sphere radius values.
Though a data product may be referenced to a datum, it is important that users understand sphere-based
projections technically have no datum. Any sphere-based output will not contain any datum information.
It will instead contain information pertaining to its spheroid. It will be up to the user to keep track of the
datum to which the data is referenced. In addition, the GCTP/Geolib software prevents datum conversions
when an initial datum is not known. Thus, if a product is output without a datum it can no longer be
converted to another datum using the MRT software.
The datum value will be used as output to HDF-EOS, GeoTIFF, and raw binary data files. The datum will
be specified in HDF for the HDF-EOS files, since HDF-EOS does not support datums. (HDF-EOS files
are assumed to be referenced to WGS84 according to the HDF-EOS documentation.)
Once the MRT knows the input and output datums and has verified that the datum/projection parameter
combinations are valid, the reprojection and datum conversion must be handled. The following are the
steps that will be followed by the MRT to reproject the input SIN data to the specified output projection
and datum.
1. Project the input data to the Geographic projection, using GCTP.
2. Convert from the input datum to the output datum, in the Geographic projection.
3. Project from the Geographic projection to the output projection.
Both steps 2 and 3 are handled by the same call to Geolib. If the input data is not in the SIN projection,
then a single call to Geolib will handle the reprojection and datum conversion.
Spectral subsetting
HDF-EOS input files contain several layers of data, which are called Science Data Sets (SDS). The term
SDS is used interchangeably in this document with the term band. Any subset of the input bands may
be selected for reprojection. The default is to reproject all input bands.
Spatial subsetting
MRT Users Manual
April 2011
A spatial subset is defined by entering two corners (upper left and lower right) of a rectangle. These
corners are specified either as input latitude and longitude coordinates, as input line/sample pairs, or as
output projection coordinates. The default is to project the entire input image, using the bounding
rectangular coordinates from the global attributes metadata.
April 2011
Parameter Files
Whether invoked via the GUI or the command line, MRT executables are directed by a parameter file
containing all the information necessary to read MODIS data from an input data file, transform the data
into a specified output projection, and write the results to an output file. The parameter file contains the
file names and file types of the input and output data files, spectral and spatial subsetting information,
output projection type, output projection parameters, output UTM zone (if necessary), output resampling
type, and output pixel size. Parameter files are generated automatically through the MRT GUI, and can be
saved for later use either through the GUI or the command line interface. They are distinguished by a
.prm extension, and formatted as ASCII text which may be created and edited in any text editor.
Starting with a base parameter file from the GUI and modifying as necessary is recommended to avoid
accidental processing errors should the user wish to construct a parameter file for command line use. The
parameter file format is described fully in Appendix A.
Metadata
MRT extracts useful information from the input files and in GUI mode displays basic file specifications,
including the number of bands available, data type, numbers of lines and samples, and the upper left and
lower right corners.
Output file metadata is written for HDF-EOS input files only (not for raw binary inputs). The output HDF
file contains the output metadata, followed by the original input file metadata. The input structure, core,
and archive metadata information is stored under the HDF attributes OldStructMetadata,
OldCoreMetadata, and OldArchiveMetadata, respectively.
April 2011
10
Background Fill
If the majority of values that lie under the resampling kernel are background fill values, then a
background fill value is output. Otherwise, resampling is performed only from non-background fill
values, and kernel weights are adjusted accordingly. MRT reads the _FillValue for each input band
and uses that value for the output background fill. If no _FillValue is specified, then the default value
is 0.
NOTE: For some MODIS products, the fill value is very high (i.e. 65535) rather than a lower value or
negative value as some users may be accustomed to. For these products, the non-image data in the
resampled image will also be background fill. This will result in very bright pixels surrounding the actual
image data, instead of the dark pixels that may be expected.
Corner Coordinates
The upper left (UL) corner specified for output in GeoTIFF refers to the center of the corner pixel. All
other corners are expressed using the HDF standard, which is the outer extent of the UL and lower right
(LR) corners. Both HDF-EOS and raw binary MRT output coordinates thus represent the UL corner of
the corner pixel. Any output corner coordinates specified by the GUI, in the status box, or by the
command line, in standard output or to the log file, represent the outer extent of the pixel.
Log File
MRT writes logging and status information to a screen display and also to a log file. The log file is named
resample.log, and is written into the bin directory (e.g., C:\MRT\bin\resample.log). Details of MRT
activity are appended to the log at the completion of every run, so the history of every MRT execution is
recorded ad infinitum. The log is an ASCII text file which users may edit or print with standard text file
tools.
The command-line version of the resampler will allow the user to specify the path and name of the
resample.log file, using the g option. The options for the resampler are fully described later in the
Bounding Tiles
Bounding tiles have presented some difficulties for the MRT. These tiles occur on the outer edge of the
Sinusoidal globe as seen in the gridded figure below.
MRT Users Manual
April 2011
11
The tiles are labeled from top to bottom and from left to right starting at 00. The horizontal tiles range
from h00 to h35, and the vertical tiles range from v00 to v17. The MODIS HDF-EOS filename will
contains a field specifying the horizontal and vertical location of the tile. For example, a tile covering the
state of Florida, USA would be named something like
MOD13Q1.A2011042.h10v06.005.20011060132568.hdf, where h10v06 indicates its tile location on
the Sinusoidal grid. Data over the southern tip of Africa might be named
MO09A1.A2007177.h19v12.005.2009081231246.hdf, where h19v12 is its tile location.
Bounding Tile Issue
Bounding tiles are unique in that they contain corner points with projection coordinates which do not map
to a valid latitude/longitude. For example, tile h10v02 over Alaska theoretically has corner points along
both the far western and far eastern edges of the Sinusoidal globe. Bounding tiles wrap around the edges
of the Sinusoidal globe, which places coordinates in discontinuity space (i.e., in the black space in the
figure above). This is not unique to MRT or MODIS tiles and impacts any global projection software.
This discussion will be limited to MRT handling of the MODIS tiles. The discontinuity space for the
Sinusoidal projection (as with many projections) occurs at the -180.0 / 180.0 longitude line. Along this
line, data do not cover all 10 x 10 degrees of a tile, as they do for interior tiles. The blank space is
populated with fill data to complete the tile.
MRT Users Manual
April 2011
12
The projection coordinates of one to three corner points in a bounding tile fall in the discontinuity space.
In this case, the MRT will process the tile as usual, but issue a warning to the user. It will cite that a
certain corner point does not have a valid latitude/longitude, and will be adjusted accordingly. When MRT
passes bounding tile projection coordinates into the transformation package, GCTP provides the output
latitude and longitude values. Because of their proximity to the 180.0/-180.0 line, the returned longitude
values wrap around it and fall on the other side of the Earth. When these GCTP coordinates are further
passed to the forward mapping algorithm, the output projection coordinates will not match those of the
input.
For example, the upper right corner of MODIS bounding tile h27v03 falls in discontinuity space and
therefore it longitude will map to the other side of the 180.0/-180.0 line.
The Sinusoidal projection coordinates for this tile are as follows:
UL x,y in meters = 10007554.677000, 6671703.118000
LR x,y in meters = 11119505.196667, 5559752.598333
Upper right and lower left corners are derived by squaring off the tile:
UR x,y in meters = 11119505.196667, 6671703.118000
LL x,y in meters = 10007554.677000, 5559752.598333
The following are the longitude/ latitude corners provided by GCTP inverse mapping:
UL long,lat in degs: 179.999999954516 59.999999994612
UR long,lat in degs: -160.000000050532 59.999999994612
LL long,lat in degs: 140.015144391778 49.999999995507
LR long,lat in degs: 155.572382657536 49.999999995507
The UR longitude above (-160) has extended beyond the eastern hemisphere, past the 180 line, and 20
degrees into the western hemisphere. The associated forward mappings from the above latitude/longitude
values likewise indicate the UR corner has wrapped around the 180 line into discontinuity space, as
shown below.
UL x,y in meters = 10007554.677000002936 6671703.117999996990
UR x,y in meters = -8895604.162390576676 6671703.117999996990
LL x,y in meters = 10007554.677000001073 5559752.598332998343
LR x,y in meters = 11119505.196667000651 5559752.598332998343
April 2011
13
The forward mapping coordinates above do not match the original squared-off upper right corner.
Bounding Tile Solution
The solution for handling the bounding tiles first detects that a latitude/longitude pair has wrapped around
the Earth by running forward mapping on the inverse mapping to validate the latitude/longitude values. In
the case that the forward mapping projection values are the same 6 as the original projection corners, then
the latitude/longitude values will be used directly. In the case that the forward mapping projection values
are not the same, the software will constrain the longitude values at -179.900 (for the upper or lower left
corners) or 179.900 (for the upper or lower right corners). Because the longitudinal values returned by
the GCTP fall in the discontinuity space (wrap around backwards), MRT signs the longitude as opposite
of the GCTP value. For example, a GCTP return of -180.000 will be written as +179.900 by MRT.
The longitudinal constraint was not set strictly to 180.0 or -180.0 to avoid the risk of running into
further discontinuity issues when going to output space. Enforcing longitudinal bounds at 179.900 and
-179.900 on the example over h27v03 used above, the latitude/longitude corners provided by the inverse
mapping are changed as shown in the table below. The Lat (fixed) and Lon (fixed) values are finally
converted to output space to define a minimum bounding box in which to project the input data.
Corner
Lat (pre-fix)
Lon (pre-fix)
Lat (fixed)
Lon (fixed)
UL
59.999999994612
179.999999954516
59.999999994612
179.999999954516
UR
59.999999994612
-160.000000050532
59.999999994612
179.900000000000
LL
49.999999995507
140.015144391778
49.999999995507
140.015144391778
LR
49.999999995507
155.572382657536
49.999999995507
155.572382657536
A tolerance value of 5-m was used to determine if the original projection coordinates and the forward mapping
projection coordinates are the same value. This tolerance value should be sufficient for MODIS tiles, but if this
software is used in the future for data from other higher resolution images then a more appropriate tolerance value
will be needed for processing those products.
April 2011
14
Pre-Installation
Users no longer need to carefully place software or files in directories with no spaces in their path names,
as required by previous MRT versions. As of version 4.1, MRT will install and run in any specified
directory. This applies to both the MRT and Java directories. Further related to directory paths, it is also
no longer necessary to use forward slashes (/) instead of backslashes (\) during MRT installation to
Windows platforms. Backslashes are in fact now recommended when entering directory paths during
installation.
Otherwise, there are a couple of pre-install checks that users are encouraged to address to ensure
successful installation and execution of MRT software. First note that entry of full pathnames during
installation is highly recommended for all directories. Wildcards (?,*) and relative pathnames are
accepted, but the MRT may or may not set up correctly.
Second, in order to run the MRT GUI, installation of a current version of Java 8 is required (at least the
Java 2 Runtime Environment version 1.5 or the Java 2 SDK version 1.5 or later). If the only intent is to
use the command line interface, Java is not necessary and this requirement can be ignored, but GUI
operations will not execute without a current Java version.
The Java directory path is needed during the installation process, so have this information available
during installation. On Windows platforms, Start/Search can be used to locate the Java directories on
the system.
7
April 2011
15
On UNIX-based systems such as Linux and Macintosh, type which java to determine the path to the
existing Java executable. This method will work only if the Java executable is on the current path. Typing
find / -name java will also work, but this will search all mounted file systems and may take time to
complete. If necessary, ask a system administrator where the Java bin directory is located.
If the Java executable is on the current path, the version of Java installed on the machine can be
determined by typing java version, which will output something similar to this:
java version "1.5.0"
If the version number is older than 1.5.0, the MRT GUI is not guaranteed to work. In this case, installing a
newer Java version is recommended.
Automatic Installation
1. Step one for automatically installing the MRT to either Windows or UNIX systems (Linux or
Macintosh) is unzipping the MRT_download_<platform>.zip file.
2. Step two is to collect the following information to facilitate successful and efficient installation.
The complete pathname of the directory in which MRT will be installed (full pathnames are
recommended over wildcards). The default will create a MRT subdirectory in the current
directory, but users have the option to enter a different directory path if preferred.
The pathname of the directory containing the Java executable program ( java or java.exe).
This pathname is not necessary on UNIX platforms if the Java executable is on the current path,
in which case it will be found automatically. See the information at the start of the Installation
section for hints on how to determine the location of the Java bin directory.
3. Step three is using a command line interface to navigate to the directory to which
MRT_download_<platform>.zip was unzipped. On Windows systems, it will contain the four
April 2011
16
Start\Programs\Accessories.
C:\Program Files\MRT> mrt_install
5. Step five is to carefully follow the instructions appearing in response to the install command. The
program will prompt the user to enter a preferred location for the install, and the information needed
to set up path and environment variables correctly. Providing full pathnames for all directories is
advised because although wildcards (?,*) and relative pathnames will be accepted, they are likely to
keep MRT software from setting up correctly. Use copy/paste functions if possible when entering
directory paths. Typographical errors will not be recognized during the installation process, and could
result in display or execution errors.
6. Step six is a recommended system or session restart to ensure the changes made during MRT
installation take effect.
April 2011
17
11. Click OK to choose an icon from the list or specify a different file
12. Type in the path and name for the ModisTool.ICO file, or use the Browse button to find the
ModisTool.ICO file, which should be in the MRT bin directory
13. Press OK, then OK
The MRT icon should now be available on the desktop. When the icon is double-clicked, the MRT GUI
should appear.
Manual Installation
Three steps are required for manual installation of the MRT:
Update the system variables to include PATH, MRT_HOME, and MRT_DATA_DIR information for
MRT.
Edit the GUI script in the MRT bin directory to reflect the system directory structure.
Below are instructions for manually working through these steps. The first section is relevant to UNIX
systems and includes specifics for C shell and Bourne shell. The second section is relevant to Windows
systems and includes specifics for NT/ME/XP.
Manual Installation Instructions for UNIX Platforms
1. Step one for manual installation of the MRT to a UNIX-based system such as Linux or Macintosh is a
two-part extraction process to load the necessary files to the users system. First, unzip the
MRT_download_<platform>.zip file downloaded from the LP DAAC Tools Web site. Use the
command unzip or ./unzip from a UNIX terminal to inflate the download package to a chosen
location.
unzip zipfile d MRTdownload_directory
compilation), and MRTdownload_directory is the directory to which the zip contents will be
extracted.
If an error is returned saying unzip: command not found, try using a preceding ./ as shown
below.
MRT Users Manual
April 2011
18
Changing to the MRTdownload_directory in the UNIX terminal, the file mrt_install should be
present along with either MRT_Linux.zip, MRT_Linux64.zip, or MRT_Mactel.zip.
The second part of the extraction process will inflate the MRT software package. Use the unzip
command to extract the installation software to a chosen location.
unzip zipfile d MRT_directory
where
zipfile
is
MRT_Linux.zip,
MRT_Linux64.zip,
or
MRT_Mactel.zip,
and
MRT_directory is the directory into which MRT will be installed. For example, to install in a My
MRT subdirectory in the home directory on a Linux workstation, type the following.
unzip MRT_Linux.zip d $HOME/My MRT
2. Step two will add MRT information to the startup files for the current shell (csh, tcsh, sh, bash).
Typing echo $0 or echo $SHELL at the command prompt will display which shell is being used.
C shell (csh, tcsh) users will need to add or update the path, MRT_HOME, and MRT_DATA_DIR
environment variables to the system .login file in the home directory. Assuming installation of
MRT in a My MRT subdirectory in the home directory, the following lines are appended to the
.login.
set path = ( $path:q $HOME/My MRT/bin )
setenv MRT_DATA_DIR $HOME/My MRT/data
setenv MRT_HOME $HOME/My MRT
Bourne shell (sh, bash) users will likewise add or update the path, MRT_HOME, and MRT_DATA_DIR
environment variables to the system .profile and .bash_profile file in the home directory, in
addition to setting the path to the Java executable. The following lines are appended to .profile or
.bash_profile files in the home directory.
#!/bin/sh
PATH=$PATH:$HOME/My MRT/bin
MRT_DATA_DIR=$HOME/My MRT/data
April 2011
19
MRT_HOME=$HOME/MRT
export MRT_HOME PATH MRT_DATA_DIR
Note that the final statement starting with " <path_to_java_bin>/java is all on one line. Do
not break this statement into multiple lines.
These changes will not take effect without restarting a new login session. Also be aware that each
new installation will append the environment variable statements to the startup files, so it is advisable
to remove these lines prior to a new install.
3. In step 3, the ModisTool shell script used to run the MRT GUI is created manually. This script will
configure the variables PATH, MRT_HOME, and MRT_DATA_DIR. The ModisTool script can be
generated in any text editor and should be saved to the MRT bin directory. Below is an example that
can be copied as a template for creating this file using any text editor. It assumes the directory
structure used in the examples above.
Make sure to replace all directory information in the template to reflect the structure of the host
machine.
Note that the final statement indicating the Java path is all on one line. Do not break this statement
into multiple lines.
Save the file in the bin (e.g., /home/user/My MRT/bin) as ModisTool.bat.
A system restart is advised to ensure the changes made during MRT installation take effect and the
tools function as expected.
C shell (csh, tcsh) ModisTool template:
#!/bin/sh
#
#
#
#
******************************************
* ModisTool
*
* C Shell script for running the MRT GUI *
******************************************
# Set the
directory.
MRT_HOME
environment
variable
to
the
MRT
installation
April 2011
20
***********************************************
* ModisTool
*
* Bourne Shell script for running the MRT GUI *
***********************************************
# Set the
directory.
MRT_HOME
environment
variable
to
the
MRT
installation
MRT_HOME="$HOME/My MRT"
export MRT_HOME
# Set the MRT_DATA_DIR environment variable to the data directory.
MRT_DATA_DIR="$HOME/My MRT/data"
export MRT_DATA_DIR
# Set the PATH environment variable to include MRT executables.
PATH="$HOME/My MRT/bin:$PATH"
export PATH
# Run the MRT Java GUI.
"<path_to_java_bin>/java" -jar "$HOME/My MRT/bin/ModisTool.jar"
1. Step one for manual Windows installation is unzipping the MRT software, which is a two-part
process. First unzip the MRT software package downloaded from the LP DAAC Tools Web site
(MRT_download_Win.zip). This can be done automatically common tools like WinZip. For
example, right click on the zip, select WinZip then Extract to, and create a directory for the
April 2011
21
Second, the unzip.exe will be used to extract the files needed for installation from C:\Program
Files\MRT\MRT_Win.zip. From Start\Programs\Accessories, open a Command Prompt
screen, change to the directory containing the files just extracted ( C:\Program Files\MRT), and
type the following command.
unzip MRT_Win.zip d MRT_directory
where MRT_directory is the directory in which the MRT will be finally installed. For example, to
install the MRT in C:\Program Files\MRT\Tool, type the command as follows.
unzip MRT_Win.zip d c:\Program Files\MRT\Tool
2. Step two is to update the system variables to recognize the PATH, MRT_HOME, and MRT_DATA_DIR
needed to run MRT.
Windows NT/XP users must edit their user keys to add the MRT PATH, MRT_HOME, and
MRT_DATA_DIR
Prompt
window from
Start\Programs\Accessories and type regedit at the DOS prompt. Administrative privileges may be
needed to complete this step.
This
will
bring
up
GUI
containing
user
key
information.
Double-click
on
the
HKEY_CURRENT_USER key then click on the Environment key. The current user key environment
variables and their values will be listed on the right hand side of the GUI. If the keys
MRT_DATA_DIR, MRT_HOME, and PATH do not exist, go to the Registry Editor menu bar at the top
of the GUI and click Edit. From there, select New then String Value to create a new user key.
The keys for PATH, MRT_HOME, and MRT_DATA_DIR should be listed in the right pane of the
Registry Editor. Each can be double-clicked to modify their values. Continuing with the above
example, the PATH would be modified to add c:\Program Files\MRT\Tool\bin to the end of the
current string, entering a semi-colon to separate directories in the path. The MRT_HOME would be set
to c:\Program
Files\MRT\Tool,
and
Files\MRT\Tool\data. It is recommended that any previous values specified for these keys are
removed. Close the Registry Editor after the keys have been updated.
April 2011
22
3. In step 3, the ModisTool.bat script used to run the MRT GUI is created manually. This script will
configure the variables PATH, MRT_HOME, and MRT_DATA_DIR for the GUI. The .bat can be
generated in any text editor (such as Notepad), and should be saved to the MRT bin directory.
Below is an example that can be copied as a template for creating this file. It assumes the directory
structure used in the examples above.
Make sure to replace all directory information in the template to reflect the structure of the host
machine.
Note that the final statement starting with c:\Program Files\Java is all on one line. Do not
break this statement into multiple lines.
Save the file in the bin (e.g., c:\Program Files\MRT\Tool\bin) as ModisTool.bat.
A system restart is advised to ensure the changes made during MRT installation take effect and the
tools function as expected.
@@echo off
rem
rem
rem
*****************
* ModisTool.bat *
*****************
4. To add an icon to the desktop, please see the direction following the Automatic Installation section
above.
April 2011
23
Version
Libraries
Link
zlib
1.2.3
libz.a
http://www.zlib.net/
szip
2.0
libsz.a
http://www.hdfgroup.org/release4/obtain.html
jpeg
6b
libjpeg.a
http://www.hdfgroup.org/release4/obtain.html
tiff
3.8.2
libtiff.a
http://remotesensing.org/libtiff/
Geotiff
1.2.3
libgeotiff.a
http://trac.osgeo.org/geotiff/
hdf4
4.2r1
libdf.a
libmfhdf.a
hdf-eos
2.14
Libhdfeos.a
http://www.hdfeos.org/software/
April 2011
24
When compiling the tiff and hdf4 libraries, make sure to include their respective dependencies to
the szip, jpeg, and zlib libraries. The Geotiff library depends on the tiff library and the hdfeos library depends on the hdf4 library. If compiling on Windows with a native compiler, then the
above library names may not have a .lib extension instead of a lib prefix (e.g. libz.a would
be called z.lib).
Once the third-party libraries are built, copying them into the $MRT_HOME/lib directory will make
modifying the Makefile easier. Likewise, copying all the third-party include files into the
$MRT_HOME/include directory will ease Makefile changes.
2. Step 2 (Modifying the Makefiles): This step may be skipped if building on a supported platform.
Otherwise, note that MRT actually consists of three libraries and many programs, each having their
own Makefile. There is a top level Makefile as well, that merely iterates through the library and
program directories that it then builds using their respective Makefiles. Some systems cannot read
Makefiles and use their own proprietary method of building (Visual Studio for C/C++ on Windows
for example), and it would probably be best to set up the project manually through the IDE. The
MRT directory structure can be shown as follows:
MRT
\
|-- shared_src
(library)
|-- gctp
(library)
|-- geolib
(library)
|-- append_meta
(program)
|-- dumpmeta
(program)
|-- hdf2rb
(program)
|-- hdflist
(program)
|-- mrtmosaic
(program)
|-- resample
(program)
|-- sdslist
(program)
Examine each Makefile to determine what changes to certain flags will be needed to tailor the build
for a specific system. All programs are written in C, so some of the flags are centered on what the C
MRT Users Manual
April 2011
25
compiler, linker, and archive are expecting. Other flags indicate commands to copy, remove,
and move files. The following lists the compile flags used by the Makefiles.
Flag
Description
CC
The CC flag indicates the compiler to be used. It could be set to gcc, cc, or xlc, for
example, depending on system particularities.
CFLAGS
The CFLAGS flag indicates any switches that need to be passed on to the C compiler. For
GNU C, -O3 -Wall -W -Wno-switch is used for example. Users need to figure out what
switches apply to their C compiler.
LDFLAGS
The LDFLAGS flag indicates the libraries and switches to be passed on to the linker. One
switch that is used for supported platforms to pass to the GNU linker is the -s switch,
which strips the executable of any debug information. The libraries needed depends on
the application being built.
AR
The AR flag indicates the archive command that needs to be run to create the static or
dynamic library. The current setting is set at ar rcsv.
CP
The CP flag indicates the command to copy files and the current setting is set to cp.
RM
The RM flag indicates the command to remove a file and the current setting is set to rm
f.
MV
The MV flag indicates the command to move a file and the current setting is set to mv.
3. Step 3 (Building the applications): Once the Makefiles are set up, there are a couple ways to build
the applications. The easiest way is to go to the top level ($MRT_HOME) directory and then issue the
following commands.
make
make install
The make clean command removes any object files and other miscellaneous temporary files. The
make command builds the executables. The make install command moves all the executables to
April 2011
26
append_meta,
dumpmeta,
hdf2rb,
hdflist,
mrtmosaic,
resample,
sdslist,
and
update_tile_meta. This may be useful if only one or two programs are being worked on.
4. Step 4 (Build ModisTool): The ModisTool is written in Java. Under the JavaGuiSrc directory is
a small script that builds the ModisTool.jar file and places it into the $MRT_HOME/bin directory.
The script is called compilejava and it works under Cygwin or a shell, although it should be fairly
easy to modify to run under DOS.
As of version 4.1, ModisTool is built with Java version 1.5.0, with scripts targeting the same. The
software should build under later releases of Java as well.
April 2011
27
Parameter Files
Regardless of how it is invoked (via the GUI or the command line) the MRT executables are directed by a
parameter file containing all the information necessary to read MODIS data from an input data file,
transform the data into a specified output projection, and write the results to an output file. The parameter
file contains the file names and file types of the input and output data files, spectral and spatial subsetting
information, output projection type, output projection parameters, output UTM zone (if necessary), output
resampling type, and output pixel size. Parameter files are generated automatically through the MRT GUI,
and can be saved for later use either through the GUI or the command line interface.
They are
distinguished by a .prm extension, and formatted as ASCII text which may be created and edited in any
text editor. Starting with a base parameter file from the GUI and modifying as necessary can help avoid
accidental processing errors should the user wish to construct a parameter file for command line use. The
parameter file format is described fully in Appendix A.
Below is an example of a parameter file. Double quotes may or may not be necessary, depending on how
the host system handles spaces in directory paths or file names.
INPUT_FILENAME = D:\My
MRT\Inputs\MYD09GA.A2007113.h24v02.005.2007116092027.hdf
SPECTRAL_SUBSET = ( 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0 )
SPATIAL_SUBSET_TYPE = INPUT_LAT_LONG
SPATIAL_SUBSET_UL_CORNER = ( 65.0 127.0 )
SPATIAL_SUBSET_LR_CORNER = ( 61.0 154.0 )
OUTPUT_FILENAME = D:\My MRT\Output\MOD09GA.tif
April 2011
28
RESAMPLING_TYPE = BILINEAR
OUTPUT_PROJECTION_TYPE = GEO
OUTPUT_PROJECTION_PARAMETERS = (
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0 )
DATUM = NoDatum
PIXEL_SIZE = 500
The
sample
parameter
file
shown
above
specifies
that
the
input
data
file
is
resampling. The output pixel size for all bands is set to 500 to overcome potential inconsistency between
the native 463.3-m MODIS pixels and other 500-m data sets. The output will be written to the GeoTIFF
file MOD09GA.tif. Since the UL and LR corner points were not specified, the bounding coordinates from
the input files global attributes will be used for the output corner points.
Resample Tool
From the command prompt, typing resample, resample help or resample help=param in
the MRT bin directory results in a brief usage message that lists various command line arguments used to
execute MRT. These are the fields typically included in a parameter file, but via command line, any or all
of them may be modified. Detailed descriptions of each parameter field follow the usage message below.
MODIS Reprojection Tool v4.1 March 2009
Usage: RESAMPLE -p parameter_file [options]
Options that override parameter file specifications:
-i input_file_name
-o output_file_name
-r resampling_type [NN BI CC NONE]
-t projection_type [AEA ER GEO HAM IGH ISIN LA LCC MERCAT MOL PS SIN TM UTM]
-j projection_parameter_list ["p1 p2 ... p15"]
-s spectral_subset ["b1 b2 ... bN"] If using the s switch, the SDSs
should be represented as an array of 0s and 1s. A 1 specifies to
process that SDS; 0 specifies to skip that SDS. Unspecified SDSs will
April 2011
29
not be processed. If the s switch is not specified, then all SDSs will
be processed.
-a spatial_subset_type [INPUT_LAT_LONG INPUT_LINE_SAMPLE OUTPUT_PROJ_COORDS]
-l spatial_subset ["ULlat ULlong LRlat LRlong"]
-or-
-or-
If using an input parameter file (recommended) the only required command line argument is the
parameter file9 name. To run the MRT resample from the command line, type:
resample p <parameter_file>
If a parameter file is not used, or if only certain fields require changes, command line arguments will set
the parameters directly and override parameter file specifications. MRT is sensitive to the lower case font
used for command line arguments.
To override any parameter file option, or to run resample without a parameter file, the following
arguments may be typed into the MRT command line interface.
-i input_filename Input MODIS level-2G, -3, or -4 HDF-EOS file.
-o output_filename Output filename, including extension ( .hdr, .hdf, or .tif) to set the output
file type. Output filenames follow a convention to identify the input product and bands used in the
operation.
-o namegame.tif
Output Filenames:
namegame.surf_refl_b01.tif
9
April 2011
30
namegame.surf_refl_b02.tif
namegame.250m_quality.tif
For multi-dimensional products, 3rd and 4th dimension slices are names as follows:
<SDS name>.<3rd dimension name>_#.<4th dimension name>_#
where # is a two-digit value representing the data slice for the associated dimension. Obviously if the
product only has three dimensions, the <4th dimension name>_# will not appear. This naming
convention is used for the output filenames, the output HDF-EOS band names, and the band names in
the GUI.
The 3-D and 4-D naming convention produces long names when the band name, 3rd dimension name,
and 4th dimension name are all of substantial length themselves. Currently the HDF-EOS library for
the Windows platform will support only 57 characters for band names, which produces problems with
the MRT naming convention on the Windows platforms. For the Windows platforms, if the output
band name is going to be longer than 57 characters, the naming convention is then changed as follows
to produce smaller output band names.
<SDS name>.3_#.4_#
-r resampling_type Resampling kernel type (CUBIC_CONVOLUTION, NEAREST_NEIGHBOR, or
BILINEAR). The default is NEAREST_NEIGHBOR.
-t output_projection_type Output projection short name. Valid values are AEA (Albers Equal
includes up to 15 projection parameters, with each value separated by white space ( p1 p2 ...
p15). If there are fewer than 15 values specified in the list, the remaining values will be set to zero.
10
See Appendix C for more information about projection parameters, or type resample help=<projection> at the
command line.
April 2011
31
-s spectral_subset_list Name of band (Science Data Set, or SDS) to resample. This is a quoted,
binary list with each value separated by white space ( 1 0 1 0.1 0). 0 means do not use this
band, while 1 means select this band. If there are fewer values in the list than input bands, the
remaining bands will not be selected (i.e., will default to 0). Use the index number (0-based) after the
band name to identify a 2D slice of a 3D band.
-a spatial_subset_type Type of output spatial subset value. Valid options are INPUT_LAT_LONG
(latitude and longitude in decimal degrees), INPUT_LINE_SAMPLE (input line and sample), and
OUTPUT_PROJ_COORDS (output projection x and y). The default is LAT_LONG, and the value
specified for this field must match the type of values specified in the spatial_subset_list.
-l spatial_subset_list
in this quoted, floating-point list must correspond with the spatial_subset_type field. For
example, spatial_subset_type=INPUT_LAT_LONG, then spatial_subset_list should
consist of the UL corner latitude, UL corner longitude, LR corner latitude, LR corner longitude. To
input coordinates by line and sample, a quoted integer list consisting of the start (UL corner) line,
start (UL corner) sample, end (LR corner) line, and end (LR corner) sample may be used. The third
option is to specify the output projection coordinates of the UL and LR corners. Thus it may be a
quoted floating-point list consisting of the UL projection x, UL projection y, LR projection x, and LR
projection y values. Values must appear in the specified order, separated by white space.
Latitude/longitude and projection x/y values should represent the outer extent of the UL and LR
corners of the subset.
-x pixel_size Output pixel size. This may be specified for each band processed, in output projection
units (meters for all projections except Geographic which requires decimal degree units). For
example, a user who selected five bands for processing and wishes to output one of the bands at a
different resolution would enter the following command.
-opsz=1000,1200,1000,1000,1000
Otherwise, the default is to output to the same resolution as the input for each band, which generally
is the same for each band. This field is optional, but given the native pixel resolution of MODIS
swath data, it may be used to normalize the output pixels (e.g., change 926.6-m input to 1,000-m
output).
If the number of output pixel sizes entered in this field is less than the number of bands processed,
then the last pixel size entered will be used as the pixel size all bands. For example, it is not
MRT Users Manual
April 2011
32
necessary to write out the output resolution for all bands if the same output resolution is desired for
all bands. Simply entering -opsz=1000 will apply the desired output pixel size to all bands selected
for processing.
-u UTM_zone Output zone number, relevant only for UTM projections. Valid values are 60 to +60.
-g log_filename This option allows the user to specify the path and name of the log file. The default
the specified output file format (based on the input and output filename extensions). The format
converter will support spectral and spatial subsetting, but it will not execute any resampling. It is
necessary to include values for projection information in the parameter file in order for the
reformatter to run, but all resampling-related inputs will be ignored during format conversion. The
output projection type, output projection parameters, output pixel sizes, and output data types will be
the same as the input.
Mosaic Tool
MRT provides a mosaic tool (mrtmosaic) for mosaicking tiles together prior to resampling. The mosaic
tool requires that all input files are of the same product type and they must contain the same band names,
band dimensions (number of lines and samples), band projection types and projection information, band
pixel size, etc. If the band characteristics for each input tile do not match, then the mosaic tool will exit
with an error.
The mosaic tool requires an input parameter file which lists the full path and filename of each input file to
be mosaicked. The input files can be listed in any order and the mosaic tool will determine how they fit
together in the mosaic. The mosaic tool also requires an output filename. The file type of the output file
must match that of the input files. Thus, if the input files are HDF-EOS then the output file extension
must be .hdf.
Typing mrtmosaic at the command prompt will display the following usage information. The last
statement in the usage message will be an alert that no processing parameters were included in the
command (mrtmosaic).
April 2011
33
To simply mosaic multiple tiles (such as prior to resampling), create a parameter file listing the input
filenames. Then type the following command all on one line. Note that the output file must be in .hdf
format.
mrtmosaic i </directory/input_file_name_list.prm> -o
</directory/output_mosaic.hdf>
To run the resample executable on the mosaic (such as to reproject, reformat, or subset), create a
standard parameter file, using output_mosaic.hdf as the input file.
Spectral subsetting is allowed in mrtmosaic by using the s command line switch. The h switch will
provide the user with header information for output mosaic. The t switch will output the h##v## tile
information read from the horizontal and vertical tile information embedded in the HDF-EOS metadata.
For raw binary files, the tile information must be specified in the filename itself. Thus if the user wants to
April 2011
34
use the t switch with mosaic tool, the input filenames must contain _h##v##somewhere in the
filename. The mosaic tool will exit with an error if the tile information is not available.
The status information from the mosaic tool will specify the order of the input files in the output mosaic.
In the following example, file[0] refers to the first file listed in the parameter file, file[1] refers to
the second file, and so on. When the input files do not provide a rectangular output mosaic, then sections
of the mosaic are filled with a background value. MRT reads the _FillValue for each input band and
uses that value for the output background fill. If no _FillValue is specified, then the default value is 0.
In the Mosaic Array (see below), fill areas are designated as file[-9].
MODIS Mosaic Tool (v4.1 March 2009)
Start Time:
file[ 1]
file[-9]
file[-9]
file[-9]
file[-9]
file[ 2]
file[ 3]
70.000000000000 120.006250000000
UR:
70.000000000000 180.000000000000
LL:
50.000000000000 120.006250000000
LR:
50.000000000000 180.000000000000
6671703.118599000387 7783653.638365999795
April 2011
35
UR:
11119505.197665000334 7783653.638365999795
LL:
6671703.118599000387 5559752.598833000287
LR:
11119505.197665000334 5559752.598833000287
band
1) Land_Cover_Type_1
End Time:
UINT8
2400
4800 926.6254
min
max
0
254
fill
255
Finished mosaicking!
April 2011
36
April 2011
37
OUTPUT_PROJECTION_PARAMETERS = (
6370997.0 0.0 0.0
0.0 -100.0 45.0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0 )
DATUM = NoDatum
OUTPUT_PIXEL_SIZE = 1000
The parameter file is edited and saved for each of the input files, changing the input and output filenames
for each file. This can be a manually intensive process if large numbers of files are required (see below
for description of the automated batch processing functions in MRTBatch.jar).
Parameter File List:
MOD14A2.A2005.prm
MOD14A2.A2006.prm
MOD14A2.A2007.prm
MOD14A2.A2008.prm
MOD14A2.A2009.prm
.....
Then a batch file is written to encapsulate the repetition of resample execution on each file.
Batch File sd_fire.bat:
resample p=MOD14A2.A2005.prm
resample p=MOD14A2.A2006.prm
resample p=MOD14A2.A2007.prm
resample p=MOD14A2.A2008.prm
resample p=MOD14A2.A2009.prm
.....
And finally, the batch file is run from the command prompt window.
Executing Batch Command:
April 2011
38
C:\Program Files\MRT4.1\MRT\bin>sd_fire.bat
This example reprojects every HDF-EOS file in the current directory using a single parameter file
prmfile.prm. The input and output filenames are changed in the parameter files for each file. The
output is written to GeoTIFF with the same base filename as the input file.
Any of the fields listed in the previous Resample Tools section can be modified as direct arguments
MRT Users Manual
April 2011
39
Create parameters files for each input and write a batch script
The sections above on Batch Processing describe the functions wrapped into MRTBatch.jar which
automates this otherwise very manual process. To use MRTBatch.jar follow the steps below.
1.
Step one is to simply gather all input files in an exclusive directory (containing nothing but MRT
input).
2.
Step two will create a base parameter file using the MRT GUI. Open one input file in the GUI
and enter the desired parameters (see MRT GUI section below). Instead of clicking Run at the end,
Click Save Parameter File to save the resulting .prm. Then exit the MRT GUI.
3.
Step 3 invokes the MRTBatch.jar to create parameter files ( .prm) for each input file in the
input data directory. It also writes out a batch script that is later used to execute the processing jobs
(MRTBatch.bat).
From the Command Prompt window, navigate to the MRT bin directory. This is where the .jar file
lives. Type the following command to initiate parameter file and batch script generation (place all fields
in one line; i.e., do not break this statement into multiple lines).
java
jar
MRTBatch.jar
input_directory
parameter_directory\
input_parameter_file o parameter_file_directory
where
input_file_directory
is
the
directory
in
which
all
input
files
are
placed
(e.g.,
April 2011
40
C:\Project\InputFiles);
parameter_file_directory is the directory where the parameter file created using the GUI ( -p) was
saved and to which the parameter files built by this application will be written ( -o);
input_parameter_file is the parameter file was saved from the GUI (e.g., mrtauto_test.prm).
command line, which will result in a prm directory containing the new parameter files being built in the
input_file_directory instead.
4.
Step four will run the MRTBatch created just above. The MRTBatch.bat contains a list of
commands to run the MRT on every input file according to the parameter files.
Change directories at the Command Prompt to go to the MRT bin directory. Tell MRT what to do by
typing the directory path and name of the batch file, such as shown below.
Windows:
C:\Program Files\MRT\Tool\bin\mrtbatch.bat
UNIX:
$HOME\My MRT\bin\mrtbatch
The results of the processing job will echo out in log form on the command prompt display, and when
completed, files should be ready in the output directory specified in the original base parameter file.
April 2011
41
GUI indicates a configuration error, most likely in the PATH to the Java executables on the host machine.
See Manual Installation instructions above to determine how to check and resolve any such errors. The
ModisTool.bat (Windows) or ModisTool (UNIX) may need to be edited to identify a valid Java path.
Another potential reason is that a session restart was not completed after the software installation.
To run resample from the GUI, users need to fill in the various fields and click Run. In general,
complete fields in the order listed, working down the left ( Source) side and progressing down the right
(Destination) side. For example, spectral and spatial subsetting parameters may not be selected until
an input file is opened, output projection parameters may not be entered until an output projection type is
specified, etc. The contents of any field may be changed at any time prior to running resample. Simply
click on the field and make the desired changes.
Along the top left banner on the GUI is a menu bar labeled with File, Action, Settings, and Help.
The File menu includes options for opening an input file, opening a parameter file, or exiting the GUI.
Other options for specifying an output file and saving a parameter file become active on the File menu
after Source information (the fields on the left side of the pane) and Destination information (right
side) have been entered respectively. These File options mirror the button functions on the GUI.
April 2011
42
The Action menu includes the Run and Convert functions, and is simply an alternative to clicking the
Run and Convert Format buttons on the bottom right side of the GUI. Use the Settings menu to set
the default directory locations for input files, output files, and parameter files. This is useful, as otherwise
MRT will default to its bin directory for everything. The Help menu contains About information, and
will open a popup displaying the version and release date for the installed MRT.
Opening an Input File
Start on the left pane of the GUI, where Source information is entered. Click Open Input File to the
right of the Input File field. This will pop up an input file selection dialog box, allowing selection of
the desired input file by pointing and left-clicking with the mouse. The default directory is set to the
April 2011
43
MRT bin, so users need to either set a preferred directory using the Settings menu on the GUIs top
banner, or navigate to the directory containing the input files using the browse tools in the dialog box.
These include a drop-down directory tree search, a button to move up one directory, a button to return to
the users home directory, a button to create a new directory, and options to list or show details of the files
in the open directory.
If several adjacent tiles are desired for processing, MRT will allow selection of multiple input filenames.
This is discussed later in the Mosaic Tool section below.
An input file is selected either by typing its name into the File Name field at the bottom of the dialog
box, by double-clicking on the file name in the directory list, or by highlighting the file name with a
single click and pressing Open.
When an input file is opened, Source information is loaded into the GUI. The file name will appear in
the Input File field, basic metadata will be displayed in the Input File Info window, the
Selected Bands window will list the science data sets (bands) available in the input file, and the corner
April 2011
44
Metadata Examination
The basic metadata displayed in the Input File Info window includes the input projection type
(Sinusoidal), the input projection parameters, the total number of bands, the data type of each band, the
pixel size of each band, the number of lines and samples in each band, and the corner coordinates of the
tile. Users may examine detailed metadata by highlighting the filename in the Input Files box, then
clicking on View Metadata below the Open Input File button. This will pop up the internal
metadata from the input HDF-EOS tile, including its inventory metadata, archive metadata, and its grid
structure.
MRT Users Manual
April 2011
45
The View Metadata window offers a Find service in the lower left corner, into which a case sensitive
text string can be typed to parse the internal metadata for terms of interest.
Tile Locator
Just beneath the View Metadata window is another button labeled View Selected Tile. This
feature will bring up a global map on the Sinusoidal grid, and highlight the location of the tiles in the
Input Files box in light blue.
April 2011
46
Spectral Subsetting
Immediately below the Input File Info box are options for spectral subsetting. By default, all
available bands are selected and appear in the box to the right ( Selected Bands). To exclude certain
bands from processing, click on the desired band and use << to deselect it. This will move it to the box on
the left (Available Bands). To move bands from the Available box to the Selected box, click on
the desired band and use >> to select the band for processing. Shift-Click and Ctrl-Click are useful
for highlighting multiple bands for selection.
In the example below derived from an 8-day MODIS Fire tile, one of the two available bands has been
removed from processing by moving it to the Available Bands box.
Spatial Subsetting
Unless otherwise specified, MRT will project the entire input file using the Bounding Box coordinates
defined in the HDF-EOS Archive metadata (displayed in the Input File Info window). Users have
the option to override this default and extract spatial subsets from any input tile. Spatial information is
entered in the bottom third of the Source pane. Users can define subset corner points either in input or
output space by selecting Input Lat/Long, Input Line/Sample, or Output Projection X/Y
from the Spatial Subset drop-down.
April 2011
47
The UL Corner and LR Corner are populated with the bounding coordinates by default. These fields can
be edited to specify an area of interest by simply clicking in the box and entering the bounds of the
desired subset. If the Spatial Subset type is set to Input Lat/Long, enter corner points in decimal
degrees. To subset using Input Line/Sample, specify line/sample pairs using a zero-based coordinate
system assuming the upper left corner is (0,0).
MRT will use Input Lat/Long or Input Line/Sample to automatically compute the other two
rectangle corners (upper right and lower left) in input space. All four corner points will be projected into
output space, using the map projection specified later on the Destination side of the GUI. A minimumbounding rectangle is computed in output space that contains the four projected points. All points inside
this rectangle in output space are mapped back into input space for projection.
When creating a subset based on Output Projection X/Y, these coordinates must be specified in the
same units used for the projection (i.e., decimal degrees for Geographic and meters for all other
projections). The upper right and lower left corners will be computed from the specified UL Corner and
LR Corner to create a rectangle in output space defined by the map projection specified later. These
output corners are mapped back to input space to determine their location in input space.
The final product after processing should have the same image corner coordinates as specified by the user,
but note that MRT will adjust the lower right corner based on output pixel size if its location does not fall
in an integral number of lines and samples.
The MRT expects that the upper left and lower right corner point values of any input or output HDF-EOS
file, whether appearing in the Input File Info or entered in Spatial Subset, will reflect the outer
extents of the image (i.e. upper left of the upper left and lower right of the lower right) not to the center of
the upper left and lower right pixels. Be aware however, that GeoTIFF output will be tagged with
coordinates from the center of pixel.
Specify Output File
After entering all the necessary Source information, the next step is to define the Destination
parameters. The first is the name of the output file, which is user-defined through a dialog box invoked by
clicking the Specify Output File button on the top of the right pane on the GUI. Similar to the
dialog for opening files, output file naming is done by navigating to a preferred directory, then selecting
an existing file, or by typing in a new output file name, as shown below. Recall that a preferred default
directory for all output files may be configured using the Settings menu on the top banner of the GUI.
MRT Users Manual
April 2011
48
MRT will expect a file extension appended to the file name, and will not accept a name without it. The
file extension indicates the file format of the output image. Adding .hdf will tell MRT to output to HDFEOS, .tif to output to GeoTIFF, and .hdr to output to raw binary.
If an existing file is selected without modifying the file name, an overwrite warning will pop up.
The output file format also determines how many files will be delivered at the end of processing. HDFEOS output consists of one file, and however many bands were processed are packed as science data sets
within the file. GeoTIFF and raw binary formats store one band per file, so each band selected for
processing results in an output file. The user does not need to specify a new output GeoTIFF name for
each selected band, as the band name is automatically appended to the base output file name.
For example, if both bands in a MOD14A2 tile were processed ( QA and FireMask), HDF-EOS output
would consist of a single sd_fire_2006.hdf, while in GeoTIFF the same output would be delivered as
sd_fire_2006.QA.tif and sd_fire_2006.FireMask.tif.
April 2011
49
Resampling Type
MRT offers three resampling methods from the Resampling Type drop-down list (Nearest Neighbor,
Bilinear, or Cubic Convolution). Note that when projecting thematic data sets, such as a fire mask
or any QC band, nearest neighbor is required to avoid mixing categorical values. For example, if 1 =
snow, 2 = water, and 3 = fire, resampling methods using averaging will potentially mix 1 and 3 and output
a 2.
April 2011
50
Clicking the Edit Projection Parameters button will pop up a dialog box in which users may enter
or edit up to 15 gridding parameters. Note that the default values appearing in the pop up box are not
automatically overwritten when their fields are clicked.
replacement. Integer values are automatically be converted to floating point. Some parameter fields will
be grayed out (uneditable) when they are not used for a particular output projection. These fields are
based on the table of projection parameters in Appendix C.
When editing the projection parameters, an output datum may be specified. For all projections, the default
will be NoDatum. The Datum Conversions section of this manual discusses more information on this
field, but it is important to iterate that either a Datum or the first two projection parameters may be
specified, but not both. If both are specified, then the MRT will exit with an error.
A special note for UTM projections: MRT will automatically set the UTM Zone when UTM is set as the
Projection Type. Although it is an option, it is not necessary to enter a UTM Zone value in the Edit
Projection Parameters box.
A special note for Lambert Conformal Conic projections: Although the standard parallels and latitude of
origin fields are both open for editing, enter a value into only one or the other. Setting standard parallels
effectively does the job of the latitude of origin in LCC projection, and having the OriginLat specified
as well as the STDPR1 and STDPR2 will place the projected output at inaccurate latitude/longitude
coordinates.
MRT Users Manual
April 2011
51
extension with the name and a file with the extension .prm is created in the directory of choice (see the
sample parameter file included in the Batch Processing section). An existing file name may be used,
but the file will be overwritten unless it is modified. If the last parameter file used for processing was not
saved, it is retrievable from the MRT bin directory, where the most recently executed parameters are
saved in TmpParam.prm.
To restore saved parameters, simply click Load Parameter File, navigate to the desired .prm and
click Open. This will restore all the parameters in the Source and Destination fields on the GUI. The
fields can be edited any time prior to clicking Run. The saved .prm can also be used to feed command
line processing (see Batch Processing section).
Executing resample
Having entered all the desired Source and Destination parameters for projection, click Run either on
the bottom of the GUIs right pane, or under the Action menu on its top left. As resample executes, a
Status window will pop up to display job progress. Its contents are simultaneously being appended to a
processing log that tracks every MRT session. The log is useful for troubleshooting, and is found in the
April 2011
52
MRT bin as resample.log. The log is an ASCII text file that users may edit or print with standard text
file tools.
When the Run button is clicked, the GUI creates a temporary parameter file ( TmpParam.prm) in the bin
directory and runs resample using that parameter file ( resample p TmpParam.prm). This file is
overwritten on subsequent runs, but not deleted, so it can be examined with any ASCII text file
viewer/editor when processing is complete.
Exiting the GUI
To exit the MRT GUI, click the Exit button or click File, Exit on the menu bar on the top banner on
the GUI. The standard operating system commands (e.g., double click on the X in the upper right hand
corner of the window, in Microsoft Windows).
April 2011
53
Format Conversion
The previous section Resampling Tool, directed use of the MRT GUI to execute the resample
software. The MRT also provides a file format converter, which allows conversion from input HDF-EOS
to output GeoTIFF or raw binary without resampling.
Running the format converter is similar to the resample option (please see section above for details on
parameters discussed here). The Input File information must be specified first, then the Output
File name and Output File Type. As with resampling, the default for format conversion is to process
all bands across the entire tile unless otherwise specified. Spatial and spectral subsetting are supported in
format conversion, so those parameters may be input as well.
Unlike the resampling process, Resampling Type, Output Projection Type, Output
Projection Parameters, and Output Pixel Size are not used for file format conversion. The
converter will use output files with specifications identical to the inputs for these parameters, ignoring
any entries to these fields on the GUI
To perform a file conversion, simply click the Convert Format button, next to the Run button at the
bottom right of the GUI, or use the Convert Format option under the Action menu on the top banner
of the GUI. Either will be grayed out (unclickable) until the information described above is entered.
Mosaic Tool
The MRT will allow the user to specify several input files to be processed. The MRT will mosaic the
input tiles into one large image, then process that image as specified by output parameters entered by the
user. Processing several tiles is very similar to processing a single tile. The only difference is that multiple
tiles are selected in the Open Input File process.
The following example shows the user selecting four tiles for processing. The user may select multiple
files by using the Shift and Ctrl keys along with pressing the left mouse button. The Shift key will
select all files between the previous mouse click and the current mouse click. The Ctrl key will simply
add the current mouse click to the list of files.
April 2011
54
The mosaic tool requires that all input tiles are of the same product type and thus contain the same bands
which remain the same size, data type, projection, pixel size, etc. for all input tiles. If the input tiles are
not of the same product type, the MRT will exit with an error.
When multiple tiles are mosaicked, the output is in HDF format and named TmpMosaic.hdf. The
TmpMosaic.hdf is input to subsequent resampling actions. The HDF4 libraries currently included in
MRT software impose a 2 gigabyte (GB) limitation on file sizes, so it is possible for MRT to reject
processing because TmpMosaic.hdf file size exceeds this limit. This has been observed when numerous
tiles are input for mosaicking (e.g., Africa), but is dependent on the data type. A 250-m product has more
volume than a 1,000-m product, and so a mosaic of twenty tiles with 1,000-m pixels may be more
successful than the same for 250-m pixels.
April 2011
55
Credits
The MODIS Reprojection Tool was developed as a collaborative effort between the Land Processes
Distributed Active Archive Center at the U.S. Geological Survey Earth Resources Observation and
Science Center and the South Dakota School of Mines & Technology.
Contacts
LP DAAC is the main user support facility for this tool. Download and installation assistance, bug
reports, and other comments may be addressed to:
LP DAAC User Services
U.S. Geological Survey (USGS)
Earth Resources Observation and Science Center (EROS)
47914 252nd Street
Sioux Falls, SD 57198-0001
Phone: 605-594-6116
Toll Free: 866-573-3222
Fax: 605-594-6963
Email: lpdaac@usgs.gov
Web: https://lpdaac.usgs.gov
April 2011
56
11
In the command-line MRT, space around tokens is not required. List values may be separated by either white
space or commas.
April 2011
57
The input data file name is a required field that provides requisite processing information. Only MODIS
HDF-EOS file names are accepted. The file name may contain a directory path. UNIX users are advised
to enclose file names in double quotes. An invalid file name or non-swath product will generate an
error.
SPECTRAL_SUBSET = ( band1 band2 bandn )
This field is optional; by default, all input image bands will be selected. This is an n-element array of
binary values corresponding to the n bands (Scientific Data Set or SDS elements) in the input data set. In
this array, a 1 indicates that a band was selected, and a 0 indicates that it was not. If there are fewer binary
values than input image bands, the remaining bands will not be selected. If there are more binary values
than input image bands, the extra values will be ignored.
SPATIAL_SUBSET_TYPE = < INPUT_LAT_LONG,INPUT_LINE_SAMPLE,OUTPUT_PROJ_COORDS >
This field is required only if spatial subsetting is desired. Spatial subsets may be defined using input
latitude and longitude coordinates, input lines and samples, or output projection X and Y coordinates. If
neither of the corner parameters (see below) is specified, this field defaults to INPUT_LAT_LONG and the
entire image will be processed.
SPATIAL_SUBSET_UL_CORNER = < ( UL_line UL_sample ),( UL_lat UL_lon ),
(UL_proj_x UL_proj_y ) >
SPATIAL_SUBSET_LR_CORNER = < ( LR_line LR_sample ),( LR_lat LR_lon ),
(LR_proj_x LR_proj_y ) >
These fields are required for spatial subsetting and define the coordinates of the upper-left and lower-right
corners in units appropriate to the selected SPATIAL_SUBSET_TYPE. By default, the entire input image will
be selected. The bounding rectangular coordinates in the input files metadata are used to determine the
image coordinates.
The parameter field is formatted as follows for each subset type.
SPATIAL_SUBSET_TYPE = INPUT_LAT_LONG
SPATIAL_SUBSET_UL_CORNER = -1.969280203 37.840197592
SPATIAL_SUBSET_LR_CORNER = 26.054383372 16.574757586
SPATIAL_SUBSET_TYPE = INPUT_LINE_SAMPLE
SPATIAL_SUBSET_UL_CORNER = 20 20
SPATIAL_SUBSET_LR_CORNER = 1353 2029
April 2011
58
SPATIAL_SUBSET_TYPE = OUTPUT_PROJ_COORDS
SPATIAL_SUBSET_UL_CORNER = 635521.0 1235874.0
SPATIAL_SUBSET_LR_CORNER = 137256.0 82544.0
In the case of multi-resolution data sets, the highest resolution of any spectral band is assumed for
line/sample values. MRT expects float values (containing a decimal point) to define input latitude and
longitude coordinates, and integer values to indicate line/sample pairs. If any entered value is float, then
INPUT_LAT_LONG will be assumed. Note that spatial subsetting takes place in the input image space, not
The output file name is required. The name may optionally contain a directory path. UNIX users are
advised to enclose file names in double quotes. A file extension must be included as it is used to
automatically determine output file type (.hdr = Raw Binary, .hdf = HDF-EOS, .tif = GeoTIFF). An
invalid or missing extension will generate an error. Note that an existing file with the same name as
specified in OUTPUT_FILENAME will be overwritten by resample.
RESAMPLING_TYPE = < NN, BI, CC >
This field is optional. The default resampling type is NEAREST_NEIGHBOR (NN) unless specified as
BILINEAR (BI) or CUBIC_CONVOLUTION (CC).
OUTPUT_PROJECTION_TYPE = < AEA, ER, GEO, GOODE, HAM, ISIN, LA, LCC, MERCAT,
MOL, PS, SIN, TM, UTM>
This field is required for resampling, but optional for format conversion. The output projection type may
be one of the following: Albers Equal Area (AEA), Equirectangular (ER), Geographic (GEO), Interrupted
Goode Homolosine (GOODE), Hammer (HAM), Integerized Sinusoidal (ISIN), Lambert Azimuthal (LA),
Lambert Conformal Conic (LCC), Mercator (MERCAT), Molleweide (MOL), Polar Stereographic (PS),
Sinusoidal (SIN), Transverse Mercator (TM), Universal Transverse Mercator (UTM).
OUTPUT_PROJECTION_PARAMETER = < p1 p2 p3 p4 p5..p15 >
This field is optional, but recommended for resampling success. The array field contains the 15 output
projection parameter values12. By default, all projection parameter values are set to zero, with the
exception of UTM. When the first two UTM projection parameters are zero, the projection will default to
the scene center. Projection parameter values are floating point and any integer values entered are
automatically converted to floating point. If there are fewer than 15 projection parameter values specified
12
See Appendix C for more information on projection parameters. Or type swath2grid help=<projection> at the
command line.
April 2011
59
the remaining values are set to zero. If there are more than 15 values specified, the extra values will be
ignored. Coordinate values (latitudes and longitudes) should be entered in decimal degrees.
UTM_ZONE = < zone number >
This is optional for users selecting UTM output projection type. MRT will choose the appropriate zone
value by default, but one may be otherwise specified. Valid values are 60 to +60. If present, the
UTM_Zone overrides values specified in the output projection parameters field.
DATUM = < NAD27, NAD83, WGS66, WGS72, WGS84 >
This field is optional, and defaults to NODATUM. Otherwise a valid datum may be specified for output
projections. If the NODATUM option is used, then the user must specify the spheroid semi-major and semiminor axes in the projection parameters. See the Datum Conversions section for more information.
OUTPUT_PIXEL_SIZE = < value >
The output pixel size may be specified for each band processed, in output projection units (meters for all
projections except Geographic which requires units of decimal degrees). For example, if five bands are
selected for processing, and the user wishes for some reason to output one of the bands at a different
resolution, the line in the parameter file would look like this below.
OUTPUT_PIXEL_SIZE = 1000,1200,1000,1000,1000
Otherwise, the default is to output to the same resolution as the input for each band, which is generally the
same for each band. This field is optional, but given the native pixel resolution of MODIS swath data,
users may utilize it to normalize the output pixels (e.g., change 926.6-m input to 1,000-m output).
If the number of output pixel sizes entered in this field is less than the number of bands processed, then
the last pixel size entered is used as the pixel size all bands. For example, it is not necessary to write out
the output resolution for all bands if the same output resolution is desired for all bands. Simply entering
the following will apply the desired output pixel size to all bands selected for processing.
OUTPUT_PIXEL_SIZE = 1000
April 2011
60
- header file
MOD09GA.A2000072.sur_refl_b01_1.dat
MOD09GA.A2000072.sur_refl_b02_1.dat
etc.
Because of these naming conventions, there is no need to specify raw binary data filenames inside the
header file. Data filenames are automatically generated by appending the appropriate extension onto the
basename of the header file.
April 2011
61
# UR_CORNER_XY = ( x y )
# LL_CORNER_XY = ( x y )
# LR_CORNER_XY = ( x y )
NBANDS = n
BANDNAMES = ( band1 band2 ... bandn )
DATA_TYPE = ( t1 t2 ... tn )
NLINES = ( r1 r2 ... rn )
NSAMPLES = ( c1 c2 ... cn )
PIXEL_SIZE = ( s1 s2 ... sn )
MIN_VALUE = ( v1 v2 ... vn )
MAX_VALUE = ( v1 v2 ... vn )
BACKGROUND_FILL = ( f1 f2 ... fn )
DATUM = {Optional datum value}
BYTE_ORDER = {little_endian or big_endian}
April 2011
62
Notes
Fields may occur in any order. Each field should begin on a new line, but may span more than one
line for readability. Field values should be separated by white space. Otherwise, there are no
significant restrictions on field formatting.
All text following a # on a line is considered to be a comment. Some comment lines are
automatically generated by MRT for reprojection to a raw binary output image, for informational
purposes only.
Field names should be largely self-explanatory. Lower-case items represent numeric and string values
for the various fields. Several fields require arrays of n values for imagery containing n bands (SDS
elements). Different bands may have different data types, dimensions, resolutions, etc.
The BANDNAMES field is optional; by default, bands are named according to their SDS name. The
MIN_VALUE, MAX_VALUE, and BACKGROUND_FILL fields are also optional; by default, no
Only one input projection type is permitted in this file format. All 15 projection parameters must be
specified.
When inputting UTM data types, either the UTM_ZONE or first two projection parameters may be used
to specify the zone. Valid UTM_ZONE values between 60 and 60 may be entered. If both the
UTM_ZONE and first two projection parameters are specified, then the UTM_ZONE is used to determine
the zone.
A DATUM may be specified for input data. Valid values are NAD27, NAD83, WGS66, WGS72, WGS84,
and NODATUM. If not specified then NODATUM will be used and the first two values in the projection
parameters must be entered to define the semi-major and semi-minor axes of the spheroid.
April 2011
63
The BYTE_ORDER parameter specifies the byte-ordering used for the raw binary product. Valid values
are little_endian (Intel-based systems like Windows) and big_endian (Unix-based systems
like Linux and Macintosh). The byte order is required since it is possible that the input file was
processed on a system with a different byte-order, in which case the image would need to be byteswapped upon ingest. As of MRT 4.0, two-byte and four-byte data types are stored in machinedependent byte order. All previous versions output raw binary products as big-endian byte-order.
The COORDINATE_ORIGIN is an optional comment field that is not used by the MRT on input, but is
written on output for information purposes only. It specifies the location of the coordinate origin as
one of the four corners (UL, UR, LL, LR). The resampling executable assumes the coordinate origin is
UL for raw binary data.
There are two sets of corner coordinate fields. The CORNER_XY coordinates (in projection units) are
optional comment fields. These fields are not used by the MRT on input, but are automatically
generated on output for informational purposes only. The CORNER_LATLON coordinates are required
(latitude and longitude in decimal degrees).
Valid DATA_TYPE values are INT8, UINT8, INT16, UINT16, INT32, UINT32, and FLOAT32.
April 2011
64
Array Element
|---------------------------------------------------|
|7 | 8|
----------------------------------------------------------------------------0 Geographic
1 U T M
|Lon/Z |Lat/Z |
2 State Plane
|SMajor|SMinor|STDPR1|STDPR2|CentMer|OriginLat|FE|FN|
4 Lambert Conformal C
|SMajor|SMinor|STDPR1|STDPR2|CentMer|OriginLat|FE|FN|
5 Mercator
|SMajor|SMinor|
|CentMer|TrueScale|FE|FN|
6 Polar Stereographic
|SMajor|SMinor|
|LongPol|TrueScale|FE|FN|
7 Polyconic
|SMajor|SMinor|
|CentMer|OriginLat|FE|FN|
8 Equid. Conic A
|SMajor|SMinor|STDPAR|
|CentMer|OriginLat|FE|FN|
Equid. Conic B
9 Transverse Mercator
|SMajor|SMinor|STDPR1|STDPR2|CentMer|OriginLat|FE|FN|
|SMajor|SMinor|Factor|
|CentMer|OriginLat|FE|FN|
10 Stereographic
|Sphere|
|CentLon|CenterLat|FE|FN|
11 Lambert Azimuthal
|Sphere|
|CentLon|CenterLat|FE|FN|
12 Azimuthal
|Sphere|
|CentLon|CenterLat|FE|FN|
13 Gnomonic
|Sphere|
|CentLon|CenterLat|FE|FN|
14 Orthographic
|Sphere|
|CentLon|CenterLat|FE|FN|
|Sphere|
|Height|
|CentLon|CenterLat|FE|FN|
16 Sinusoidal
|Sphere|
|CentMer|
17 Equirectangular
|Sphere|
|CentMer|TrueScale|FE|FN|
18 Miller Cylindrical
|Sphere|
|CentMer|
|Sphere|
|CentMer|OriginLat|FE|FN|
|FE|FN|
|FE|FN|
April 2011
65
|OriginLat|FE|FN|
|Sphere|
|CentMer|
|FE|FN|
|IncAng|AscLong|
|FE|FN|
|FE|FN|
23 Alaska Conformal
|SMajor|SMinor|
|FE|FN|
24 Interrupted Goode
|Sphere|
25 Mollweide
|Sphere|
|CentMer|
|FE|FN|
26 Interrupt Mollweide
|Sphere|
27 Hammer
|Sphere|
|CentMer|
|FE|FN|
28 Wagner IV
|Sphere|
|CentMer|
|FE|FN|
29 Wagner VII
|Sphere|
|CentMer|
|FE|FN|
|Sphere|
|Shapem|Shapen|CentLon|CenterLat|FE|FN|
|CentMer|
|FE|FN|
-----------------------------------------------------------------------------
Array Element
|-----------------------------------|
| 10 |
11 | 12 | 13 | 14 | 15 |
-----------------------------------------------------------------0 Geographic
1 U T M
2 State Plane
4 Lambert Conformal C
5 Mercator
6 Polar Stereographic
7 Polyconic
April 2011
66
8 Equid. Conic A
|zero |
|one
10 Stereographic
11 Lambert Azimuthal
12 Azimuthal
13 Gnomonic
14 Orthographic
16 Sinusoidal
17 Equirectangular
18 Miller Cylindrical
|Long1|Lat1|Long2|Lat2|zero|
|one |
21 Robinson
|PSRev|LRat|PFlag|
|zero|
|one |
23 Alaska Conformal
24 Interrupted Goode
25 Mollweide
26 Interrupt Mollweide
27 Hammer
28 Wagner IV
29 Wagner VII
|Angle|
31 Integerized Sinusoidal
|NZone|
|RFlag|
Equid. Conic B
9 Transverse Mercator
-------------------------------------------------------------------
April 2011
67
Notes
Lon/Z: Longitude of any point in the UTM zone or zero. If zero, a zone code must be specified.
Lat/Z: Latitude of any point in the UTM zone or zero. If zero, a zone code must be specified.
SMinor: If zero, a spherical form is assumed, eccentricity squared of the ellipsoid if less than one, or
if greater than one, the semi-minor axis of ellipsoid.
Factor: Scale factor at central meridian (Transverse Mercator) or center of projection (Hotine Oblique
Mercator)
April 2011
68
AziAng: Azimuth angle east of north of center line (Hotine Oblique , format B)
AzmthPt: Longitude of point on central meridian where azimuth occurs Hotine Oblique Mercator,
format B)
LRat: Landsat ratio to compensate for confusion at northern end orbit (SOM, format A -- use
0.5201613)
PFlag: End of path flag for Landsat: 0 = start of path, = end of path (SOM, format A)
Path: Landsat Path Number (Use WRS-1 for Landsat 1, 2 and 3 and -2 for Landsat 4, 5 and 6.)
(SOM, format B)
NZone: Number of equally spaced latitudinal zones (rows); must be 2 or larger and even
RFlag: Right justify columns flag is used to indicate what to do with zones with an odd number of
columns. If it has a value of 0 or 1 it indicates the extra column is on the right (zero) or left (one) of
the projection y-axis. If the flag is set to 2 the number of columns are calculated so there are always
an even number of column in each zone.
April 2011
69
All angles (latitudes, longitudes, azimuths, etc.) are entered in decimal degrees and the MRT then
converts them to packed degrees/minutes/seconds (DDDMMMSSS.SS) format for the call to GCTP.
April 2011
70