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
