Subject: Marine Geospatial Ecology Tools (MGET) help
Text archives
- From: Jason Roberts <>
- To: Raul Fonseca Valente <>
- Cc: "" <>
- Subject: RE: [mget-help] Problems with Data Products tool
- Date: Thu, 30 Mar 2017 18:16:39 +0000
- Accept-language: en-US
- Authentication-results: fc.up.pt; dkim=none (message not signed) header.d=none;fc.up.pt; dmarc=none action=none header.from=duke.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Dear Raul,
I looked into this further. It is more complicated than I thought. NASA did indeed change the scaling equation last year, but the time that it changed depends on the product. For example, the Aqua 4 micrometer product (SST4) changed on 2016 day 182 while the Terra 11 micrometer products (SST, NSST) changed on 2016 day 56. Furthermore, in those Terra products, 2016 days 51-55 are missing from the time series. They also switched their underlying data type from unsigned 16-bit integer to signed 16-bit integer and changed their No Data value.
The proper solution to this is to change MGET to determine the data type, No Data value, and scaling equation from each file individually. While this concept is simple in principle, it is actually a big change to MGET’s MODIS code, which was able to take some shortcuts by assuming these metadata did not change across the entire time series. Unfortunately I will not be able to undertake this work until June at the earliest. I’m very sorry about that, but I’m in the midst of an important project that I can’t set aside.
As a workaround, attached a version of the code that uses the new metadata. First you need to discover what date your desired MODIS product changed from the old metadata to the new metadata. Then you can switch between the existing MGET Python file and this new one, depending on which dates you are working with.
For example, if you are using Create Rasters for PO.DAAC MODIS L3 SST to acquire the daily Aqua SST4 images, then you would use the old Python code for 2016 day 181 (29 June 2016) and earlier, and the new code for 2016 day 182 and later. Let’s say you needed to acquire these images for the entire year of 2016. You would first run the tool using the old code with a Start Date of 1 January 2016 and End Date of 29 June 2016. You would then switch to the new code and run the tool for Start Date 30 June 2016 and End Date 31 December 2016.
To change which code your MGET is using:
1. First make a backup copy of your existing file C:\Python27\ArcGIS10.4\Lib\site-packages\GeoEco\DataProducts\NASA\PODAAC.py. Note that you may need to change this path to use the ArcGIS version you have installed. Keep this file safe; it is the one with the old metadata. (If you ever lose it, you can just uninstall MGET from the Windows control panel Programs and Features, then install MGET again.)
2. Now shut down all ArcGIS programs.
3. Save the attached file to the location above, overwriting the existing file. (Or, if you are switching back to use the old metadata, restore the old file to that location.)
4. Start ArcGIS and run the tool again. Check the SST values to make sure they look ok.
Best regards,
Jason From: Jason Roberts
Dear Raul,
Thanks for bringing this to our attention. Sorry for my slow response.
The problem here is that NASA appears to have changed their scaling equation for MODIS SST data sometime the middle of last year. As a result, MGET is calculating the wrong SST values for data beyond the middle of last year. (I am still tracking down the exact date of the change.)
I’m sorry I did not detect this; I did not see an announcement and am not currently using the data myself. The old scaling equation had been used for over a decade and I’m not sure why it was necessary to change it. In any case, I will update MGET to fix the problem. I’ll let you know when a new version is ready.
Best, Jason
From:
[mailto:]
On Behalf Of Raul Fonseca Valente
Dear MGET team, I have had problems with SST4 data from MODIS-Aqua satellite, since weekly data from 2016 (quality 0) sometimes seems to have wrong values (in some pixels we can see values such as (for example) 0.01) which are impossible to exist in my study area (Macaronesia). Could you tell why this happens and how can I fix/contour this situation? Thank you in advance, Raul Valente --
|
Attachment:
PODAAC.py
Description: PODAAC.py
- [mget-help] Problems with Data Products tool, Raul Fonseca Valente, 03/26/2017
- RE: [mget-help] Problems with Data Products tool, Jason Roberts, 03/29/2017
- RE: [mget-help] Problems with Data Products tool, Jason Roberts, 03/30/2017
Archive powered by MHonArc 2.6.19.