Jump to content
PDS Geosciences Node Community

Susie Slavney

Geo Staff
  • Posts

    215
  • Joined

  • Last visited

Posts posted by Susie Slavney

  1. Darren,

    The page you mentioned is part of the Orbital Data Explorer, a web service developed and maintained here at the Geosciences Node of the Planetary Data System (PDS). PDS has a general page about citation guidelines here: https://pds.nasa.gov/citation/index.shtml. Following those guidelines, I suggest you use this citation: "Images were obtained from the Orbital Data Explorer at the NASA Planetary Data System Geosciences Node, geo.pds.nasa.gov."

    Thanks for asking,

    Susan Slavney

  2. The most recent global altimetry data for Mars is from the Mars Orbiter Laser Altimeter (MOLA) on Mars Global Surveyor. The global data products are the MEGDRs (Mission Experiment Gridded Data Records), which are image maps of topography, planetary radius, areoid, and counts, available here: http://pds-geosciences.wustl.edu/missions/mgs/megdr.html.

     

    For higher-resolution coverage of a selected area of the planet, try the MOLA PEDR Query Tool, which is part of the Mars Orbital Data Explorer service. This tool can provide topography data as an image or as an ASCII table. It is available here: http://ode.rsl.wustl.edu/mars/indextools.aspx?displaypage=molapedr. This tool is useful for small areas. It would not be practical to request output for the whole planet because the resolution is so high. 

  3. [From an expert TES user we consulted:] One approach to generating the temperature maps you want is to use a software tool called "vanilla" (http://themis.asu.edu/software) which was developed by the TES team to access their data.  If you download vanilla and the binary data files from the TES database onto your local machine (except spectral data "rad*.var" files which is large and you probably do not need) vanilla works quite fast to retrieve data into an ascii format.  As I recall you will also need *.tab and *.fmt files for each data file for vanilla to work.  There may be a way to point it to a web site, but I have never tried it.

     

    For example, if you retrieve latitude, longitude, Ls, and bolometric temperature into an ascii table, you can then sort that ascii data file into the appropriate map bins using your favorite software language.   Use the *.fmt files to identify the fields you want to retrieve and the vanilla documentation for how to use it.   You may want to down select the data based on quality flags,  smear effects (depending on the intended map resolution), time of day, etc. Again, check the *.fmt files for relevant data fields.  

     

    There is a mapping tool call "dmap" you can try, but as I recall this tool is not good for global maps as it will bog down and run very slowly.  

     

    Also, there are other temperature fields you might consider aside from bolometric, which will depend on your application.  There are also a few "virtual fields" computed on the fly from the spectral data by vanilla.

     

    Hope this  information helps to get you moving.

  4. LOLA RADR (albedo) products, which were released for the first time in December 2015, have been replaced with a new set of RADRs. Only the file names have been changed; the files were incorrectly named in the previous delivery. The contents of the files have not been changed.

    With this revision the LOLA RADR data set has completed peer review.  More information about this data set is in the file RADR_DS.CAT in the Catalog directory.

     

  5. Andy,

    Please refer to the SHARAD instrument paper for details about the data processing, including compression. I'm afraid that is all I can tell you.

    Seu, Roberto, et al., SHARAD sounding radar on the Mars Reconnaissance Orbiter, Journal of Geophysical Research (112): doi 10.1029/2006JE002745, 2007.

    Susan

  6. Andy,

    Your questions are a little bit beyond my knowledge of the SHARAD data. Have you read section 4.1.3.4, Pre-Summing and Data Compression, in the SHARAD EDR Software Interface Specification? (http://pds-geosciences.wustl.edu/mro/mro-m-sharad-3-edr-v1/mrosh_0002/document/edrsis.pdf) Also, section 4.3.2, Data Product Generation, in the SHARAD RDR Software Interface Specification (http://pds-geosciences.wustl.edu/mro/mro-m-sharad-4-rdr-v1/mrosh_1002/document/rdrsis.pdf). I cannot tell you any more than what you find in those documents. If you have read them and still have questions, I will forward your questions to the SHARAD data providers.

    Susan

  7. Dear Andy,

    I will try to answer all your questions.

     

    > I have a query that the SHARAD EDR echo data are saved by 8-bit signed integer or 8-bit unsigned integer?

     

    The echo data are stored as signed 8-bit integers.

     

    > We think that e_0168901_002_ss19_700_a_s.dat. file contains the expected echo data and the file e_0168901_002_ss19_700_a_a.dat only just contains the system information as auxiliary description of the echo data. Do we have the right understanding of this EDR data?

     

    Yes.

     

    > When we extract the echo data from the file e_0168901_002_ss19_700_a_s.dat, we obtain the information that the SHARAD 1689 have 3786 bytes of each single-observations as A-scope and 4556 observations in along-track.

     

    Almost right. There are 3786 bytes in each observation and 4551 (not 4556) observations in the file. This information comes from these keywords in the label file e_0168901_002_ss19_700_a.lbl:

        ROW_BYTES              = 3786
        ROWS                         = 4551
     

    >Each observation has 3786 bytes which has last 3600 bytes contained the expected echo data, and the 3600 bytes echo data are stored as 8-bit signed integer while the header of each A--scope single observations are stored as 8-bit unsigned integer.

     

    Almost right. It is true that the last 3600 bytes in the observation contain the echo data, and they are stored as 8-bit signed integers. This part of the file is described by a label fragment (called a format file) SCIENCE8BIT.FMT in the LABEL directory of the archive. In this format file, the keyword BIT_DATA_TYPE = MSB_INTEGER means that each 8-bit value is a signed integer. (If it were unsigned, the keyword value would be MSB_UNSIGNED_INTEGER.)

     

    But the first 186 bytes in each observation are not all 8-bit unsigned integer values. Some are 8 bits, some are 32 bits (4 bytes), some are 16 bits (2 bytes), some are 4 bits. This part of the data file is described by the format file SCIENCE_ANCILLARY.FMT in the LABEL directory. These 186 bytes contain the header information for each observation.

     

    > In the edrsis.pdf file, we find that there should include file E_0123405_001_SS07_700_A.data, but we can not find this file in the data storage website.

     

    That is not a real file name; it is just an example. The SIS was written before any actual data were received, so the author made up a file name for the example.

     

    > In the  edrsis.pdf file, it describes that the e_0168901_002_ss19_700_a_s.dat. file is the Instrument data binary file and the e_0168901_002_ss19_700_a_a.dat represents Geometric information binary file, which can be found in page 15 in edrsis.pdf file. Can you explain these descriptions in edrsis.pdf file?

     

    I see these statements on page 9 of EDRSIS.PDF. The actual descriptions of the binary files are found in the format files in the LABEL directory, which are reproduced in section 7.5 of EDRSIS.PDF. The instrument data (the *a_s.dat file) is described by the format files SCIENCE8BIT.FMT and SCIENCE_ANCILLARY.FMT as I mentioned before. The geometric file (the *a_a.dat file) is described the format file AUXILIARY.FMT. There is one record in the geometric file for each record in the science data file; therefore, e_0168901_002_ss19_700_a_a.dat contains 4551 records. Each record has 267 bytes, as described in AUXILIARY.FMT. Some are 2-byte or 4-byte unsigned integers; some are 4-byte or 8-byte real numbers, and one value "GEOMETRY_EPOCH" is the UTC date and time in ASCII text.

     

    I hope this helps you read the SHARAD EDR files.

     

    Susan Slavney

    PDS Geosciences Node

     

  8. Ashton,

    I am sorry, but the MER mission has not archived any IMU/accelerometer ground data with PDS. You might check the literature to see if there are any publications about the ground data.

    Regards,

    Susie Slavney

  9. Have you tried the Mars Reconnaissance Orbiter CRISM data sets? CRISM is the Compact Reconnaissance Imaging Spectrometer for Mars. In particular, the CRISM TRDR (Targeted Reduced Data Record) might suit your purpose.

     

    Two ways to find CRISM data: 1. The Geosciences Node web page for CRISM is http://pds-geosciences.wustl.edu/missions/mro/crism.htm. 2. The Mars Orbital Data Explorer allows you to search the CRISM data sets by location, time, product ID, etc. (http://ode.rsl.wustl.edu/mars/).

     

    The CRISM team uses ENVI, and has provided a CRISM Analysis Toolkit (CAT), a set of ENVI procedures for reading, displaying and analyzing data. The CAT toolkit is available from our CRISM page, the first link above. I recommend reading the CRISM TRDR data set description here as an overview: http://pds-geosciences.wustl.edu/mro/mro-m-crism-3-rdr-targeted-v1/mrocr_2108/catalog/trdr_ds.cat, and for more detail, parts of the CRISM Software Interface Specification (SIS), here: http://pds-geosciences.wustl.edu/mro/mro-m-crism-3-rdr-targeted-v1/mrocr_2108/document/crism_dpsis.pdf. The SIS is a big, complex document and you won't want to read it cover to cover.

     

    Regards,

    Susie Slavney

  10. You do not need to combine the files. First, be sure you understand the difference between megt (topography), mega (areoid), megr (planetary radius) and megc (counts). The one you probably want is megt, topography; the others will not look like anything interesting. The label tells you the data are stored as 16-bit most-significant-byte-first (big-endian) integers. They are signed integers, by the way. Hmm, if you were treating them as unsigned, that might account for the noise you're seeing. Another idea: if you're on a Windows machine you're probably reading them as least-sig-byte-first integers, so you need to swap the bytes. You don't need to apply any math. The values are already in meters, ranging from -8208 to 21249 for the whole data set (it will be slightly different for individual tiles).

×
×
  • Create New...