Title: Abstract
1HDF-EOS vs. GeoTIFF GIS Problems when
Projection and Datum Spheroids are Different
Terry Haran National Snow and Ice Data Center,
449 UCB, University of Colorado, Boulder, CO
80309, USA
Abstract
The Problems
The Solutions
One solution to the problems with bringing MODIS
data into ArcMap would be to avoid the use of
spherical projections and only use ellipsoidal
projections with the projection spheroid set to
the WGS-84 ellipsoid so that both the GCS and the
PCS share the same spheroid as currently required
by the GeoTIFF format and ArcGIS. For example, we
can use the MRT to resample our 2400x2400
Sinusoidal tile to a Albers Conical Equal Area
projection and save it as a GeoTIFF with both the
DATUM (i.e. the GCS) as well as the projection
semimajor and semiminor axes set to WGS-84
values. Again we use ArcCatalog to convert the
GeoTIFF to a layer and drag and drop the layer
into ArcMap. This time we dont get a warning
about an unknown spatial reference, and the layer
loads just fine. Examining Data Frame Properties
Coordinate System, we see
We start with a MODIS/Terra Snow Cover Daily L3
Global 500m Grid tile acquired 7 May 2008
MOD10A1.A2008128.h13v03.005.2008130192222.hdf
which covers the Hudson Bay region in Canada. The
projection for this 2400x2400 tile is Sinusoidal
for a sphere of radius 6371007.181 meters. We use
the MODIS Reprojection Tool (MRT) to reformat the
1 byte Snow_Cover_Daily_Tile Scientific Data Set
(SDS) to GeoTIFF file MOD10A1.A2008128.h13v03_mrt.
tif. We use ArcCatalog to convert this GeoTIFF to
a layer, and drag and drop the layer into ArcMap.
We immediately get the following message window
A spheroid is a model of the earth represented by
either a sphere of a specified radius or a
prolate ellipsoid with specified values for the
equatorial and polar radii. A datum specifies
the dimensions of a specific spheroid, a point of
origin, an azimuth from the origin to a second
point, and the spatial orientation of the
spheroid relative to the earth. A Geographic
Coordinate System (GCS) assigns unique coordinate
values to locations on the surface of a spheroid.
The system is usually based on latitude and
longitude and is fully specified by a unit of
measure (typically degrees), a prime meridian and
a datum (e.g. WGS-84). A Projected Coordinate
System (PCS) is a combination of a map
projection, projection parameters, and an
underlying GCS that determines the set of x,y
coordinates (typically in meters) assigned to a
map. A projected raster data image consists of a
raster image for a specified PCS consisting of a
specified number of columns and rows, at
specified horizontal and vertical resolutions
(typically meters per cell), each cell of which
is a specified data type (e.g. a single precision
floating-point number), with the upper left
corner of the upper left cell at a specified PCS
x,y coordinate. The GeoTIFF specification as
well as many GIS applications that depend on
GeoTIFF for importing projected raster data
(including ArcGIS) appear only to support the
geolocation of a projected raster data image for
which the spheroid associated with the underlying
GCS (e.g. WGS-84) is the same spheroid used to
define the PCS (e.g. an elliptical sinusoidal
projection based on the WGS-84 spheroid). Put
another way, the dimensions of the projection
spheroid are not specified as projection
parameters but simply as inherited parameters of
the underlying GCS. For all Land MODIS level 3
projected products, the underlying GCS is WGS-84,
but the spheroid used for the projection is
either a sphere of radius 6371007.181 meters in
the case of the sinusoidal products (e.g.
MOD10A1), or a sphere of radius 6371228.0 meters
in the case of the polar EASE-Grid azimuthal
equal-area products (e.g. MOD29P1D). This means
that a valid GeoTIFF cannot be created for these
products in their "native" projection the data
must first be reprojected into a grid using the
WGS-84 spheroid as the projection spheroid before
a valid GeoTIFF may be created. The implications
of the above situation will be discussed in terms
of current MODIS products and software tools,
with suggestions for possible future enhancements
to both.
The reason we get this message is because the MRT
forces the DATUM parameter to NODATUM for
spherical projections, and so ArcMap does not
know the Geographic
This time when we add a shapefile layer of
coastlines, the layer loads just fine without a
message, and coastline and snow layers line up
correctly
Coordinate System (GCS) for this layer. We
examine the the Data Frame Properties Coordinate
System, select New Projected Coordinate System,
and select Sinusoidal as the projection. Under
GCS, we select New, and we decide to enter the
sphere as the GCS, so we enter 6371007.181 as
both the Semimajor and Semiminor axis values, set
the Angular Unit to Degree, and set the Prime
Meridian to Greenwich. This scheme gives us the
right projection spheroid, but unfortunately
ArcMap thinks the GCS is also spherical rather
than defined for the WGS-84 ellipsoid. When we
try to add a shapefile layer of coastlines
(GSHHS), we get the message
The reason we get this message is because ArcMap
thinks our snow layer has a spherical GCS, but
the coastlines have the GCS set to WGS-84 so
ArcMap thinks it needs to perform a datum
transformation of the coastlines. In reality, no
such transformation is necessary or desired since
the true GCS of our snow data is also WGS-84.
We push Close, and the coastlines are correctly
drawn over the snow data
While this approach solves the GeoTIFF and ArcMap
problems, it does require resampling the HDF-EOS
gridded data, which is not always desirable.
Moreover, it requires the use of ellipsoidal
projections, the choices of which may be limited
depending on the software package being used for
the resampling. For example, the packages that
work directly with HDF-EOS files, namely the MRT
and the HDF-EOS To GeoTIFF Conversion Tool (HEG)
support only spherical forms of the equal-area
projections used by the MODIS land products,
namely Sinusoidal and Lambert Azimuthal. Thus it
can be argued that HDF-EOS should be enhanced to
provide ellipsoidal versions of these and most of
the other projections that currently only have
spherical versions. Once that is done, then the
resampling problem could conceivably be addressed
in a future MODIS reprocessing collection that
replaced the spherical projections with
elliptical (i.e. WGS-84) projections. A
completely different approach would be to extend
both the GeoTIFF and ArcGIS specifications to
allow for a spherical projection spheroid with an
elliptical datum spheroid that is, to allow a
PCS to specify a projection spheroid that differs
from the spheroid used in the specification of
the GCS. Note that this approach is partially
implemented in ArcGIS 9.3 by supporting the use
of an Auxilliary Sphere, i.e. a PCS sphere
(usually of radius 6371007.181 m) with an area
equal to the area of the spheroid specified by
the GCS (usually WGS-84). Unfortunately this new
capability hasn't been implented for the
Sinusoidal projection in ArcGIS 9.3. It is
worth noting that ENVI software does allow for
the GCS and PCS spheroids to be different.
However, ENVI grew out of the remote sensing
community, not the mapping/GIS community. The
idea that two different spheroids would ever be
used in the specification of a single map
probably never arose prior to the satellite era,
and the remote sensing community will probably
have an uphill battle convincing the GIS
community that the (tens? hundreds?) of petabytes
of remote sensing data that currently require
such a specification are worthy of such an
accommodation.
Alternatively, if we had set the GCS to WGS-84,
then ArcMap wouldnt have thought it needed to
perform a datum transformation however, the
coastlines wouldnt have matched the snow data
because the PCS for the snow data would have been
set to an ellipsoidal sinusoidal projection
rather than the true spherical projection
So when we are dealing with spherical projections
of MODIS data in ArcMap, we cannot set the GCS to
its true value of WGS-84 and simultaneously set
the PCS to its true value of a spherical
projection we can get set one or the other
correctly, but not both.
Contact ltTerry Harangt tharan_at_nsidc.org