Hi Sohail, re: > Thanks Tom, for detail reply. No worries. re: I sense a reluctance ... > The data HDF5 is from FY2E Chinese satellite, and that data is not > available for the public. OK, interesting. Isn't FY2E a polar orbiting satellite? re: > So FY2G dataset will not contain those images. I (now) understand. This should mean that the ABoM won't have images from this satellite either. re: > And they have provided us in HDF5 format. That's the main reason i am a bit > reluctant to go for that. So i think the only option is to convert HDF5 > into some kind of AREA format. :( :( :( OK. My advice is that converting to ASCII, then to MD, then (possibly) to GRID then to IMAGE will most likely not result in an image that can be used in the ADT routines. A different approach is one where you would need to know a LOT more about how AREA files are structured and have detailed knowledge of the navigation and calibration of the images would be do dump a raster from the original image (using some tool that you may or may not have), then bring the raster into an AREA file "shell" (a template using MAKEAREA), then add navigation (MAKNAV) and calibration (PRDUTIL). The GREAT difficulties with using this approach are: - finding something to create a raster in a format that can be used by MAKEAREA - knowing the exact navigation of the original image AND this navigation being specifiable in McIDAS-X - being able to express the calibration of the original pixels (calibration is turning the original counts/pixel values into calibrated values like TEMPerature, etc.) - learning a LOT more about how AREA files are structured There are no good references in our training materials that can lead one through the process I have sketched out above. re: > My apologies, actually the reason that why I am reluctant to go for the FY2G > imagery in AREA format from the SSEC Data Center is that my current > research task is > > 1. To convert the HDF5 dataset in AREA format or any other format that can > be read by the McIDAS-X and analyze by ADT and find the way how it can be > improved. OK. re: > 2. An alternative to that is to convert the HDF5 into any other format like > ASCII files and then feed the ASCII files to McIDAS-X such that it could be > analyzed by the ADT. Again, I do NOT think that this approach will result in what you want. re: > I am sorry if there was any misunderstanding about the main reason for HDF5 > and ASCII file feeding to McIDAS-X. I was (and still am) concerned that you were trashing around for a solution without knowing enough about how McIDAS AREA files work, and even possibly about the original image data you have in HDF5 format. A software developer who spun up on programming in McIDAS might be able to develop a new ADDE server that understands the HDF5 format imagery you have from FY2E. Developing this new code would not be fast or easy. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: HMV-801244 Department: Support McIDAS Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.