MODIS Data Support

Owned by Marco Peters
Last updated: 2015-01-21
Target release
Epic SNAP-58 - Getting issue details... STATUS
Document statusDRAFT
Document owner

Marco Peters

Designer
Developers
QA

Goals

  • Gather problems and requirements we have with MODIS data. 
  • Collect the current status of our MODIS reader and the SeaDAS reader.
  • Plan actions to solve issues.

Status

  • Three reader can read the data. SeaDAS reader is 'intended', MODIS and NetCDF are 'suitable'
  • NetCDF reader provides no geo-location and band names are different to MODIS and SeaDAS and provides only raw count data
  • MODIS reader has good geo-location and provides data as radiance
  • SeaDAS reader has bad geo-location and provides data as reflectance
  • Version of our SeaDAS reader is higher as the one from SeaDAS.

Requirements and Problems

#TitleUser StoryImportanceNotes
1Geo-location of MOD021KM data is inaccurateWhen reading this type of data with the SeaDAS reader the geo-location has a shift of several pixels(star)(star)(star)(star)(star)
  • If the SeaDAS reader is removed it is not deterministic any more which reader is selected. NetCDF and MODIS reader claim to be 'suitable'.
  • Related issue: BEAM-1696
2Provide data as radiance and/or reflectance valuesThe data is given as raw count values and conversion factors to radiance and reflectance values. User shall either be able to chose between radiance and reflectance or both values shall be provided(star)(star)(star)(star)(star)
  • On the branch 'MODIS21KM_patch' in the BEAM repository there has been a system property beam.modis.MOD021KM.readAs introduced in order to allow users to switch between radiances and reflectances
  • Related issue: BEAM-1696
3Geo-location is wrong if scene crosses dateline

If the data is read by the SeaDAS reader the geo-location is wrong if scene crosses dateline. This is caused by not constructing the longitude tie-point-grid with the DISCONT_AT_180 option

(star)(star)(star)(star)(star)
  • This is already fixed for BEAM (BEAM-1740) it needs to be ported to SNAP.
  • Actually the SeaDAS guys need to be informed so they can fix it in their implementation.
4When creating a subset of a MODIS product the geo-location gets totally wrong.

The geo-location of a subset is totally wrong in certain cases. This can be best seen when using as subset_region covering only the right part of the scene (full hight).

See definition of subset.
See resulting geo-location (red shape is the subset)

(star)(star)(star)(star)(star)
  • This problem occurs in the products read by SeaDAS and by MODIS reader.
  • The SeaDAS guys have been informed about this problem, but it seems that it is not solved yet.
5MODIS Aqua product 'A****.hdf' shall also work with IDEPIX.  
  • What is this requirement about? Already solved? Who knows this requirement? Olaf Danne, GritK, KerstinS, CaroleL?
6Use SeaDAS reader directlyCurrently we use our own copy of the SeaDAS reader. This gives us the freedom to change code but is not code practice.(star)(star)(star)(star)(star)
  • The issues we have already and will identify shall be fixed tn the SeaDAS reader.
  • SeaDAS shall make a big version increment in order to overtake us.
7It shall be possible to specify the reader on the command line (gpt)In SNAP GUI the data can be imported using a specific reader. This is not possible on the command line. The reader operator has no parameter for specifying the input format.(star)(star)(star)(star)(star)
  • In SNAP GUI it solves some issues when importing the data with a specific reader but not on the command line.

 

Questions

Below is a list of questions to be addressed as a result of this requirements document:

QuestionOutcome

Not Doing