Abstract

1. HDF-EOS vs. GeoTIFF: GIS Problems when Projection and Datum Spheroids are Different Terry HaranNational 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 don’t 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 wouldn’t have thought it needed to perform a datum transformation; however, the coastlines wouldn’t 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: <Terry Haran> tharan@nsidc.org