Skip to Content.

mget-help - RE: [mget-help] Error occur when converting HDF to ArcGIS

Please Wait...

Subject: Marine Geospatial Ecology Tools (MGET) help

Text archives


RE: [mget-help] Error occur when converting HDF to ArcGIS


Chronological Thread 
  • From: Jason Roberts <>
  • To: 吴仪 <>
  • Cc: mget-help <>
  • Subject: RE: [mget-help] Error occur when converting HDF to ArcGIS
  • Date: Mon, 17 Apr 2017 12:43:38 +0000
  • Accept-language: en-US
  • Authentication-results: mail2.sysu.edu.cn; dkim=none (message not signed) header.d=none;mail2.sysu.edu.cn; dmarc=none action=none header.from=duke.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Dear Wu Yi,

 

This is an unusual problem that has never been reported before. The failure occurred when MGET examined the metadata for the Total_Attenuated_Backscatter_532 variable in the HDF file. It compared the rank (i.e. number of dimensions) of this variable listed by the metadata to the length of the list of variable names. The rank and length of the list should always be the same. But for this file, somehow they were different.

 

This suggests there is something wrong—or maybe just something very unusual—about this file. If you can send me a link to it, I will examine it to see if I can determine the problem.

 

However, I’m not sure you will have much luck with this file in the end. I am not familiar with CALIPSO, but L1 data almost always means that the data have not been placed into a regular grid. For example, for polar orbiting satellites, L1 data represent swath granules. I believe CALIPSO may be snapshots from the GOES geostationary satellites—I don’t think those are called swaths. In any case, the problem is this: even though the data come as a rectangular array, the geographic spacing between each grid cell is not constant. The distance (either in angular degrees or linear meters) is different for cells close to the center of the image as compared to cells near the edge of the image. ArcGIS’s raster processing engine cannot handle this condition. It requires grid cells to have a constant spacing. In some cases I believe the spacing may be different in the x dimension and the y dimension, but it must be constant across a given dimension.

 

So, even if we are able to get MGET to produce an ArcGIS raster for these L1 data, they will appear to be incorrectly georeferenced. When people see this and they are familiar with ArcGIS but unaware of the details of this problem, they guess that the coordinate system is not properly defined for the L1 raster and ask me to help them figure out how to define it correctly. The problem is that there is no coordinate system that works. The georeferencing problem is not a traditional matter of determining the correct map projection; it is a different problem entirely.

 

In my experience, the best way to deal with L1 or L2 data in ArcGIS is to convert them to points and then interpolate a raster from the points. Unfortunately MGET does not have generic tools for doing this. It can do this for certain L2 MODIS files, although NASA changed the format of those files and the MGET tools for them may be broken. (I have been so busy I haven’t been able to check.)

 

The GDAL library can handle this problem and includes command line programs that can produce ArcGIS compatible rasters. gdal_translate is probably the appropriate program. For Microsoft Windows, you probably want to download GDAL from here. To get help, scroll down on the main GDAL page to find the gdal-dev mailing list.

 

Best,

Jason

 

From: [mailto:] On Behalf Of ??
Sent: Sunday, April 16, 2017 11:12 AM
To: mget-help <>
Subject: [mget-help] Error occur when converting HDF to ArcGIS

 

Dear Sirs/Madam: 

I am a graduate students in Sun Yat-sen University. Recently I am using your tools to converting CALIPSO L1 data to ArcGIS Raster, and it doesn't seem to workT_T. 

 

Attach is the data I used and the describe of the error. 

error:

This function is unable to process HDF file because the number of dimensions for Total_Attenuated_Backscatter_532 appears to be inconsistent with the Rank of that SDS. Please contact the author of this function for assistance.

 

I will be really appreciated if you could help me or even just gave me some useful information! 

 

 

P.S.

I am fully aware that I must cite your paper after using your tools!

 

 

 

 

 

Regards,

Wu Yi

School of Geography and Planning

Sun Yat-sen University

 




Archive powered by MHonArc 2.6.19.

Top of Page