[user sign up and mosaic search]

Hi Jun -

We will check on the account creation and see what's going on. For the second part, I just started adding a "mosaic" category to the data search form this past Thursday. We'll put that function online as soon as we get it tested. Besides searching for anaglyph mosaics, are there any other filters or constraints you'd like to see included in the mosaic search?

Hi Tom,

thank you for your reply. I just read it because I did not get a email saying someone had replied.

 

I can not think out other constrains except for the anaglyph mosaics right now.

 

Thanks again.

Jun 

[user sign up and mosaic search]

Hi,

Thanks for the great product of Analyst's Notebook!

 

I tried to sign up a new account, but it always tells me the password was too simple. I tried some complicated combinations including letters and numbers, and it still says "it is too weak"

 

A second question is: how can I search only the red-blue mosaics of the NC? I tried to read the help file and go through all the options, but no good luck.

 

Thanks,

Jun

[Destripe Error in CAT 7.2 on ENVI 4.8 & 4.7]

Jun,

There is a bug in one of the IDL routines used for destriping that's causing the problem with that observation. I'll get a patch into the next CAT release.

 

In general you should be able to process TRR3 CRISM data without additional destripe/despike, since a noise filter has already been applied in the pipeline processing. Those routines were much more important for the old TRR2 calibration version. There may still be noisier-than-usual TRR3 data where additional filtering is beneficial, but you shouldn't have to routinely use the CIRRUS filters with TRR3 data.

 

I will patch the bug though. Thanks for pointing it out to us.

 

Frank

Thank you for your reply, Frank!

 

Thank you for the help, Jennifer!

 

Jun

[Destripe Error in CAT 7.2 on ENVI 4.8 & 4.7]

Hi there,

I have installed CAT7.2 on both centos 6 (ENVI 4.7) and win XP (ENVI 4.8), when I try "clean spectral cube" for the atmospheric corrected data (HRL0000D2E5_07_IF180L_TRR3_CAT_corr.img), it shows "Destripe Error" ( No good data in HRL0000D2E5_07_IF180L_TRR3_CAT_corr.img Aborting Destripe.)

 

I tried the one in 09 workshop (FRT000064D9_07_IF166L_TRR3_CAT_corr.img), and it shows the same error.

 

I chose "Empirically optimized for this observation" for atmospheric correction.

 

BTW, which vocanic scan method is recommended?

 

Thanks!

 

Jun

[SHARAD ground intercept points]

Hi Jun.

 

the effective spacecraft orientation in space has no effect on the real position of the radar footprint. This is because the antenna of SHARAD has very little directivity, and in effect irradiates in all directions. The real position of the radar footprint is thus the portion of the surface which is closest to the spacecraft, which could or could not be the same as SUB_SC_PLANETOCENTRIC_LATITUDE and SUB_SC_EAST_LONGITUDE.

 

In general, the flatter (i.e. not sloping) and the smoother (i.e. not rough) the surface, the closer the radar footprint is to the computed spacecraft ground track. For sloping terrain (for examples, the flanks of Olympus Mons) the only way to know I can think of is to take the MOLA planetary radii dataset (not topography) and to compute the distance of all points in the vicinity of the ground track (up to a few tens of km, to be sure). The points which result the closest to the spacecraft are those from which the first echo recorded in SHARAD data originates. You can ths consider such area as the footprint of the radar.

 

Hope this helps.

 

Roberto

 

Thank you very much!

 

Jun

[SHARAD ground intercept points]

have a question regarding the SHARAD RDR products. I noticed that the rdr.fmt

file describes several geographic parameters in each data record.

 

http://pds-geoscienc...1/label/rdr.fmt

 

Specifically, I see the SUB_SC_PLANETOCENTRIC_LATITUDE and SUB_SC_EAST_LONGITUDE.

 

I realize that this point may not coincide completely with the actual footprint of

SHARAD on the surface. That depends on how far off nadir the instrument aims.

Does SHARAD acquire data sufficiently off nadir such that I need to apply SC_YAW_ANGLE,

SC_PITCH_ANGLE and SC_ROLL_ANGLE to determine the Mars surface intercept points?

 

Are the ground intercept points perhaps described elsewhere in the rdr.fmt?

 

 

Thank you,

Jun

[How to get SHARAD data ground track]

I have a question regarding the SHARAD RDR products. I noticed that the rdr.fmt

file describes several geographic parameters in each data record.

 

http://pds-geosciences.wustl.edu/mro/mro-m-sharad-4-rdr-v1/mrosh_1001/label/rdr.fmt

 

Specifically, I see the SUB_SC_PLANETOCENTRIC_LATITUDE and SUB_SC_EAST_LONGITUDE.

 

I realize that this point may not coincide completely with the actual footprint of

SHARAD on the surface. That depends on how far off nadir the instrument aims.

Does SHARAD acquire data sufficiently off nadir such that I need to apply SC_YAW_ANGLE,

SC_PITCH_ANGLE and SC_ROLL_ANGLE to determine the Mars surface intercept points?

 

Are the ground intercept points perhaps described elsewhere in the rdr.fmt?

 

 

Thank you,

Jun

[How to get SHARAD data ground track]

Hi Susan,

Thanks for the quick reply! I really appreciate that!

 

I think it will work

 

best regards,

Jun

Jun,

The label gives you the starting and ending sub-spacecraft points for the entire SHARAD file. Each record in the file has information about a single SHARAD observation, including the sub-spacecraft latitude and longitude at the time of the observation. You'll find these in columns 77, 78, and 79 of each record. See the file RDR.FMT in the LABEL directory of the archive for a description of all the columns. Both the planetocentric and planetographic latitude values are recorded. (For an explanation of the difference, see the PDS Standards Reference, section 2.4, Body-Fixed Planetary Coordinate Systems.)

I hope this helps you.

Susan Slavney

[How to get SHARAD data ground track]

Hi all,

Greetings!

 

In the PDS node (http://geo.pds.nasa.gov/missions/mro/sharad.htm), for the Derived Data Products (DDR), the lbl files hold the information for the data file). In the lbl files, there are for values for the latitude and longitude:

 

MRO:START_SUB_SPACECRAFT_LONGITUDE = 97.749998 <DEG>

MRO:START_SUB_SPACECRAFT_LATITUDE = -24.689301 <DEG>

MRO:STOP_SUB_SPACECRAFT_LONGITUDE = 95.934470 <DEG>

MRO:STOP_SUB_SPACECRAFT_LATITUDE = -37.625862 <DEG>

 

However, if one observation has a very large latitude range (say 30 - 50 degrees), using only two points (start and end) can not show the accurate ground track (since Mars is rotating). If I only have two points and the straight line between them, it is not correct (I guess the real ground track should looks curve ?)

 

So how can I get accurate ground track for each orbit?

 

Thanks in advance,

Jun