Problem with HEG2.3 to UTM projection

[cpradera2]

Alec,

Ok, I'll elevate this higher on my to-do list (quite long ;-).



I'm off tomorrow and monday...

I'll estimate getting something to you around August 8-9

(monday-tuesday). Maybe sooner...



When it's ready, I'll let let know the anonymous ftp site to download.



Hey, I just noticed that you are getting the MODIS data

from a NOAA NESDIS site, true? Is this a public site?

I guess they've started their own archive...that's interesting.

Let me know the link if you have one.

I'm always generally interested to see how the data is

evolving in the way it gets used.



Thanks,

Cid

[cpradera2]

Alec,



Ok, I have a linux executable for you with the fix for

a) lcc

b) the rows of fill values in the lat/lon geolocations.



You can get it at my anonymous ftp site:

ftp ftp-ldo.raytheon.com (cd pub/cpradera)



The name is "swtif_for_alec".



Please test it out as soon as you get a chance.

Let me know if you have any problems.



Thanks,

Cid

[caseya]

Cid,



Thanks so much for getting th executable to me. I have tested it out with a number of HDF files that were crashing before and so far it has been fine at identifying the -999 fill values in the geolocation fields. However, there is one problems that I am having with the LCC export. In the few tests I have run it has crashed on multi-band geotiff exports. I am able to run single band exports, but if the output file is a multi-band geotiff then swtif crashes.



When attempting a multi-band export swtif succesfully completes the translation of input file 1 (The % Swath to Grid gets to 100%).



On the translation of input file 2 an error occurs when %Swath to Grid is at 0%. The error message displayed is as follows:

"% of Swath to Grid (field EV_500_RefSB, band 2) conversion: 0%problem in GDll2ij converting lat/lon to grid ij.

Encountered a problem, continuing with next request.

Translating input file 3..."



Then when translating input file 3, swtif prints the line "Swath temp files for lats/lons will require about 87901 KB of disk space (in the disk containing heg's bin directory)" and then it encounters a segmentation fault and it exits.



I have tried exporting the two bands that failed as single band Geotiffs and they work, it is just when they are being exported as a multi-band Geotiff that swtif crashes.



Please let me know if you might be able to get a multi-band export working without much difficulty. Thanks again for the work you have put into this, it is a huge help for us, and hopefully we can get the LCC export working perfectly soon.



Alec

[cpradera2]

Hi Alec,

Thanks for catching this bug. (Please bang it around with everything you've got ;-) )

That's the problem with being in

the middle of a development phase. I actually had to reorganize (make

more efficient) a lot of code for a lot of other things. It got to be easier to just give

you my development copy instead of a patch to an old version.

I couldn't test everything as I would like to at the moment. A test team will do this more

rigorously in a couple of weeks before a public release sometime in September.



Anyway, I think we should be ok - not a big deal really. I am now looking at

some Multi-Band runs. I did the Multi-Band runs (full image and spatial subset; output to GeoTIFF and output to HDF-EOS) for the Geographic projection and all seems ok. The problem is in non-Geographic projections. I'm starting to look at this more carefully. when I figure it out (hopefully soon),

I'll let you know.



Thanks,

Cid

[cpradera2]

Alec,

Ok, I think I've fixed it. Go ahead and pick up a new

executable (swtif_for_alec_02) in the same place as before.



Let me know if you find anything else,

Cid

[caseya]

Cid,

Perfect! It has worked on all of the HDFs that I have tested so far. I have incorporated this into our automated ingestion scripts so it will be tested quite rigorously now. I will let you know if anything else comes up.

Thanks,

Alec

[caseya]

Cid,



The new swtif has been working quite well. Our scripts were running overnight and out of 77 HDFs processed, 72 of them were processed succesfully. Of the five that failed, three were simply bad data. For the other two the following error was displayed:



Swath temp files for lats/lons will require about 87901 KB of disk space (in the disk containing heg's bin directory).

Finished reading/interpolating lats, doing lons .....

Error: interpolate_latlon : General Processing

: Longitude has value less than -180 or larger than 180

Fatal Error, Terminating...



The two HDFs that failed are named MOD02HKM.A2005221.0750.hdf and MOD02HKM.A2005221.0930.hdf and I have placed them on your ftp site in /pub/cpradera

The same error occurred with the MOD02QKM files for those two granules.



Alec