Problem with HEG2.3 to UTM projection

[caseya]

Hi,

I am using HEG 2.3 on a windows XP machine to convert MOD02 files to GeoTIFFs. I have succesfully used the HEG Tool on two images to do all the processing I need to do, but for the two others that I am working with I cannot create GeoTIFFs when the projection is set to UTM. Below is the last bit of the log displayed:



OUTPUT GRID:

X pixel size = 250.000000 meters number of columns = 11581

Y pixel size = 250.000000 meters number of rows = 473787



Cannot allocate memory for uint16gdbuff[89735].

Encountered a problem, Exiting.







I can see that somewhere during the processing the number of rows has become far too large and I believe this is causing the memory error. Does anyone know what could be causing the number of rows to be erroneous?

If I try to create a GeoTIFF with all of the parameters the same except the projection which I set to Geographic then the export works, why doesn't it work with UTM?

Thanks for the help.

[cpradera2]

Hello caseya,



Your right, the problem is the number of rows is much too large.

The number of columns is also very large.



It's possible the UTM zone is not being calculated correctly by HEG.

Possibly, this is due to an unusual location of your data set such as the pole area.

You can try to set the UTM zone manually and see what happens.

To calculate the correct UTM zone, use the following equation



utmzonecode = (sign) ( longitude + 180.0 ) / 6.0 ) + 1.0 ) );

where

"sign" is positive for the upper hemisphere and negative for the lower hemisphere

"longitude" is the center of the image (more or less)





If you can, place your data set in my anonymous ftp site and I will try to

recreate the problem:

ftp ftp-ldo.raytheon.com



Regards,

Cid

[caseya]

Cid,

I have been setting the UTM zone manually and the number of rows still isn't working. I have placed the four datasets that I am currently working with on your ftp site (in the folder pub/cpradera). The first two images, MOD02HKM.P2005157.1630.hdf and MOD02HKM.P2005157.1805.hdf, both worked properly and I was able to export GeoTIFFs in the UTM projection for them. The other two images, MOD02HKM.P2005160.0900.hdf and MOD02HKM.P2005160.1215.hdf, are the ones which have given me the memory allocation error due to the wrong number of rows being calculated. These two images are further north, if the problem is that they are located too close to the pole is there anyway to get around this?

Thanks again.

[cpradera2]

caseya,



I looked at the two data sets that did not work.

The problem is that the last 10 rows or so of the geolocation

data (lats/lons) are -999.0 values. I've seen sporadic -999.0 values, but

I've never seen this many.

The data set is a little quirky.



This is causing problems in the HEG code. We will have to try to

make an adjustment for this type of data anomaly in the HEG

code - hopefully soon.



In the mean time, maybe you can download another few MOD021HKM

data. You can use HDFView to check the insides and see that

the data is ok.



One of the data sets crosses the International Dateline, but I don't think

this should pose a problem with the UTM projection. The Geographic

reprojection might be a little tricky at the Dateline....I'll have to work

on this also.



Hope this helps,

Cid

[caseya]

Thanks for the help Cid. I just hope that this isn't too prevalent in the data that I will be using!

I have also started trying to export the GeoTIFFs to a custom LCC projection and have not been able to get any datasets to export with it and was wondering if you could help me with this too. The projection parameters that I input are:

1st standard parallel: 49 degrees North

2nd standard parallel: 77 degress North

Central meridian: 100 degrees West

latitude of origin: 40 degrees North

False easting: 0 metres

False northing: 0 metres



I input these into Heg as below:

STDPR1 = 49.0

STDPR2 = 77.0

CentMrd = -100.0

OriginLat = 40

FE = 0.0

FN = 0.0



When I run HEG it stalls once it has listed the projection parameters. The last lines displayed by the log are:

**** Output Projection is Lambert Conformal Conic ****

projparm[2] = 49000000.000000 DMS Degrees

projparm[3] = 77000000.000000 DMS Degrees

projparm[4] = -100000000.000000 DMS Degrees

projparm[5] = 40000000.000000 DMS Degrees



Is it just me or are the decimal points out of place? No matter which image I run Heg with it always crashes at this same spot, do you know why this occurs?

Once again thank you so much for the help



caseya

[cpradera2]

caseya,



I've never seen the situation with the quirky data in that

fashion. So, I think it's a rare occurrence.



As far as the LCC reprojection, I just tested it and it looks like HEG has a bug.

This projection was rushed in at the last second at the end

of last year and has not been tested out rigorously.

Mostly, HEG supports the DAAC datapools and their main

projections are Geographic, UTM, and PS.

So, I apologize for the problems with LCC.



I have a fix on this, but it will take a bit of time to "merge" it into the

"process" around here and make the release public - around 2 months or so.

If you really need a fix bad on this , maybe I can get an "swtif" executable

to you in our anonymous ftp site.

Just let me know.



Regards,

Cid