Thanks again Bih-Minh for your help. I was able to compile and run the hdf4 mapping tool. I think the detailed output will be very helpful for me as I parse the HDF4 files. I currently have a problem with chunked data but I know how to handle it from the output of the h4map tool.
On Mon, Jul 6, 2015 at 3:58 PM, Ahmed Eldawy <[email protected]> wrote: > I couldn't find a link to download the tool. Can you please point me to > the page that contains the download? > I've been looking at > http://www.hdfgroup.org/products/hdf4_tools > and > http://www.hdfgroup.org/products/hdf4_tools/toolsbycat.html > but I couldn't find anything related to mapping. > > On Thu, Jul 2, 2015 at 4:52 AM, Ahmed Eldawy <[email protected]> > wrote: > >> I've seen your previous comment about the HDF4 Mapping Tool. However, I >> couldn't find any instructions on how to install or use it. If the >> generated XML file looks like this >> >> http://e4ftl01.cr.usgs.gov/MOLA/MYD11A1.005/2002.07.08/MYD11A1.A2002189.h18v06.005.2007216142720.hdf.xml >> then I don't think it will be of much help to me. >> >> On Sun, Jun 28, 2015 at 11:50 PM, Ahmed Eldawy <[email protected]> >> wrote: >> >>> Hi Binh-Minh Ribler, >>> Thanks for your response. I've been looking into the issue myself and >>> I think I found the problem. I had to check the source code of the HDF >>> library and I found some useful comments in the file hblocks.c. According >>> to this file, the correct header format is >>> ext_tag_desc - SPECIAL_LINKED(16 bit constant), identifies this as >>> a linked block description record >>> elem_tot_len - Length of the entire element(32 bit field) >>> blk_length - Length of successive data blocks(32 bit field) after >>> first block, >>> first block is calculated. >>> num_blk - Number of blocks per block table(32 bit field) >>> link_ref - Reference number of the first block table(16 bit >>> field) >>> >>> As I mentioned earlier, the ext_tag_desc is 16-bits only and the >>> constant is SPECIAL_LINKED not EXT_LINKED. In addition, the value >>> first_blk_len is not actually stored in the header. It is calculated based >>> on number of blocks, the size of each block, and the total element length. >>> After I fixed these issues, the numbers started to make more sense. Do >>> you know how I can reach out to the people who write the documentation so >>> that they can solve these problems? It seems that the documentation is >>> outdated. >>> >>> On Thu, Jun 18, 2015 at 3:04 PM, Ahmed Eldawy <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> To give some background context, I'm working on a Java project that >>>> deals with HDF files. I used to use the Java-interface to the native HDF >>>> library, however, I had some issues with it and I wanted to use a pure Java >>>> library. I didn't find any pure Java HDF libraries, so I decided to make >>>> my own. It's going very fine and it fits very well in my project. It's not >>>> complete yet, but I'm extending it bit-by-bit. All my work is open source. >>>> Currently, it's part of a bigger SpatialHadoop project [ >>>> https://github.com/aseldawy/spatialhadoop2]. However, I'm planning to >>>> ship it is a standalone library which will be available for the community. >>>> >>>> Currently, I'm working on the Linked Block feature of HDF files. >>>> However, I'm having problems with this file >>>> >>>> http://e4ftl01.cr.usgs.gov/MOLT/MOD13Q1.005/2000.02.18/MOD13Q1.A2000049.h10v11.005.2006270195941.hdf >>>> The file opens fine in HDF viewer, which means that the file is >>>> correct. I'm following the HDF specs at >>>> http://www.hdfgroup.org/release4/doc/DSpec_html/DS.pdf >>>> Linked block elements are described in Section 10.3 on page 149 (160 in >>>> the PDF). First, there seems to be a problem in the documentation as it >>>> says that EXT_LINKED constant is 32-bits. This seems to be error because >>>> other extension identifiers are 16-bits (e.g., see SPECIAL_EXT in 10.4). >>>> Anyway, I fixed it myself and worked with a 16-bit identifier. However, >>>> I started to see some problems and I don't know if my fix of 32-bits to >>>> 16-bits was right or wrong. >>>> The file I mentioned above has an extended data block with tagID 1963 >>>> (DFTAG_VS) and reference no 49. The data of this object is located in >>>> offset 38215 and length 16 bytes. When I parse this block according to the >>>> specs, I get the following numbers which are inconsistent. >>>> Length: 57600 >>>> first_len: 4096 >>>> blk_len: 16 >>>> num_blk: 131072 >>>> Now these numbers do not make sense because if the length of the first >>>> block is 4096 and then we have 131072 blocks, each of 16-bytes length, the >>>> total length would be 2101248 which is much larger than 57600. >>>> I'm having more troubles when parsing the linked block table but let's >>>> resolve this issue first as the later might be related. >>>> >>>> >>>> >>> >> >
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
