OK, not "wrong", but unexpected. (I know I can tell it what I want the output file to be)
When I download A2007207165000.L1A and run modis_GEO.py, the resulting geo file is named A2007207165001.GEO. Why the change in name?
modis_GEO.py output file is "wrong"
-
OB SeaDAS - knowles
- Subject Matter Expert
- Posts: 276
- Joined: Mon Apr 07, 2008 4:40 pm America/New_York
modis_GEO.py output file is "wrong"
Bruce,
The extension GEO is a naming convention used by the OCSSW software. It designates this is a geo file (contains geographic coding information). Each OCSSW program has its default output file naming convention. If you run modis_L1B, this program will take as input a geo file and a L1A file and produce a L1B file. The unique extensions help users more readily identify the file level/type as well as help downstream programs find existing input files to use as default inputs.
Note: a geo file is NOT a L1A file with geo coding attached to it. A geo file only contains the raster info of the L1A and the related geographic coding info. Only some missions (currently MODIS and VIIRS) require a geo file in order to go between level 1A and level 1B data.
The following presentation material may be helpful on this (see slides 16-20 for data levels)
https://seadas.gsfc.nasa.gov/docs/SeaDAS_Intro.pdf
Danny
The extension GEO is a naming convention used by the OCSSW software. It designates this is a geo file (contains geographic coding information). Each OCSSW program has its default output file naming convention. If you run modis_L1B, this program will take as input a geo file and a L1A file and produce a L1B file. The unique extensions help users more readily identify the file level/type as well as help downstream programs find existing input files to use as default inputs.
Note: a geo file is NOT a L1A file with geo coding attached to it. A geo file only contains the raster info of the L1A and the related geographic coding info. Only some missions (currently MODIS and VIIRS) require a geo file in order to go between level 1A and level 1B data.
The following presentation material may be helpful on this (see slides 16-20 for data levels)
https://seadas.gsfc.nasa.gov/docs/SeaDAS_Intro.pdf
Danny
modis_GEO.py output file is "wrong"
Danny,
I get all that, but I think you missed the point of my question...
99.999% of the time (based on my experience processing data since Aqua started producing data :-), the GEO file that is produced by modis_GEO.py (and it's predecessors) will have the same basename, with an extension of GEO. In this case, the basename for the GEO file is different, with the trailing zero(0) turned into a one(1).
I know how to get around it (specify the output filename myself), but I'm curious why, in this case, the basename got mangled.
Bruce
I get all that, but I think you missed the point of my question...
99.999% of the time (based on my experience processing data since Aqua started producing data :-), the GEO file that is produced by modis_GEO.py (and it's predecessors) will have the same basename, with an extension of GEO. In this case, the basename for the GEO file is different, with the trailing zero(0) turned into a one(1).
I know how to get around it (specify the output filename myself), but I'm curious why, in this case, the basename got mangled.
Bruce
modis_GEO.py output file is "wrong"
Bruce,
Our tools use the header data to determine the name for output files. Sometimes the time in the header data does not exactly match the time tag in the input file's name. When that happens the output name will not match the input file name.
It looks like that is what happened here. The RANGEBEGINNINGTIME field in the L1A file I pulled off our direct data access web site has a value of 16:50:01.384716. (The fractional part of the seconds field is truncated when constructing the output name).
HTH!
-Matt
Our tools use the header data to determine the name for output files. Sometimes the time in the header data does not exactly match the time tag in the input file's name. When that happens the output name will not match the input file name.
It looks like that is what happened here. The RANGEBEGINNINGTIME field in the L1A file I pulled off our direct data access web site has a value of 16:50:01.384716. (The fractional part of the seconds field is truncated when constructing the output name).
HTH!
-Matt