NASA GSFC MODIS Flood Mapping Products README
Document Date: 16-Feb-2017
Product Version: 6.2
A. PROJECT INFORMATION
B. PROJECT SUMMARY
C. GEOGRAPHIC INFORMATION
D. FILENAME CONVENTION
E. PRODUCT DISTRIBUTION FORMATS & DETAILS
F. ISSUES FOR CONSIDERATION
MODIS Near Real-Time Global Flood Mapping Project
Hydrology Laboratory, Code 617
NASA Goddard Space Flight Center
Greenbelt MD 20771, USA
PI: Frederick Policelli, frederick.s.policelli at nasa dot gov
Technical Lead/Contact: Dan Slayback, SSAI, dan.slayback at nasa dot gov
Mailing list: https://lists.nasa.gov/mailman/listinfo/floodmap
The MODIS Near Real-Time Global Flood Mapping Project produces global daily surface and flood water maps at approximately 250 m resolution, in 10x10 degree tiles.
This project was developed in collaboration with Bob Brakenridge at the Dartmouth Flood Observatory (DFO):
This README document provides basic information on distributed products.
Projection: latitude/longitude geographic
Pixel size: 0.002197 degrees square (approximately equal to 250 m at the equator)
Grid: products are not on a fixed output grid; the grid of the particular input data for a given date/tile determines the output grid. Our input data are special products from the LANCE MODIS processing system at NASA GSFC (lance-modis.eosdis.nasa.gov). Typically the raster products are 4551 x 4551 pixels in size. However, this may vary by 1-2 pixels depending on the particular input data.
MFW: MODIS Flood Water
MSW: MODIS Surface Water (eg MFW before subtracting the reference water)
MWP: MODIS Water Product (combines both MFW and MSW, raster only)
MFM: MODIS Flood Map = annotated 10x10 degree map/graphic product (currently png format)
See below for additional details on products and distribution formats.
DATE: product date: YYYYDOY
YYYY: 4-digit year.
DOY: 3-digit day of year (001 to 365 or 366).
Note that most products are multi-day composites (see COMPOSITE section below), to minimize cloud cover issues. The product date is the LAST day of the composite period. E.g., the date for which the composite is most relevant. Thus, a 3D3O product dated 2012015 would include data from 2012013, 2012014, and 2012015.
TILE: upper left corner of 10-degree product tile: LONGLATI
The row of southern latitude tiles with upper-left corner on the equator are indicated as 000S, and not 000N (given that the data lie in the southern hemisphere).
Example: 000E050N is the tile covering most of France.
030E000S is the tile covering most of Tanzania.
Standard product composite: XD
2nd order product composite: P14xXDYOS and A14x XDYOS
The D and O (2nd and 4th characters) are fixed (the 4th character is a capital letter O).
X: number of Days for the product window.
Y: number of Observations required over the window, for a pixel to be labeled water.
S: Shadow masking implemented. This 5th character will be one of:
N: No shadow masking
T: Terrain shadow masking
C: Cloud shadow masking
S: both terrain and cloud Shadow masking
2D2OT: 2 Days imagery, 2 Observations required, Terrain shadow masking applied
2D1OC: 2 Days imagery, 1 Observation required, Cloud shadow masking applied
3D3ON: 3 Days imagery, 3 Observations required, No shadow masking applied
1D1OS: 1 Day imagery, 1 Observation required, both terrain & cloud shadow masking applied
Currently, two standard products are produced: 2D2OT and 3D3OT. A single-day product (1D1OS) is turned on for specific events of current interest, but is not (as of yet) run routinely.
Requiring multiple observations helps eliminate false detections due to shadows (cloud & terrain). As of product version 4.4, terrain shadow masking is now routinely applied. This eliminates some, but not all, issues of terrain shadow getting tagged as water due to their spectral similarity. As of product version 4.7, a draft version of cloud shadow masking is applied, but only to single-day products.
---------2ND ORDER 14-DAY COMPOSITES: (Production began 17-June-2013)----------
The 2nd order composite is a composite of the previous 14 days' 3-day product, to provide a recent-historical view of flooding and surface water extent, and largely overcoming patchiness in 3 and 2 day products due to clouds.
The naming convention is P14 or A14 x standard composite, = P14x3D3OT, and A14x3D3OT. Thus, this can be generated for different lengths of time, and for different base products. We have found 14 days and the 3D3OT base product to generally provide a good result, and so that configuration is routinely generated.
The 2nd order composite has two outputs:
P14: this is an integer product giving the occurrence of water as the percent of clear observations over the last 14 days' products. Only provided as geotiff. Values are percents; 50 indicates that 50% of clear looks (as defined in each 3D3O product) for that pixel were identified as water. If all 14 were clear, then 7 were positive water identifications (giving 50%) If only 4 were clear, then 2 of those products reported water, again resulting in a 50 value in the geotiff. Because vectorizing multiple values would be problematic, we provide the simplified A14 version for vector outputs (shapefile and kmz)
A14: this is a binary, 0-1 product, provided in geotiff, shapefile, and kmz format. Value is 1 in the geotiff if the P14 value was greater than zero. E.g., for any water observation over the previous 14 3-day products, A14 will be 1, and shapefile and kmz will show polygons for such regions.
There is also a MFM png product, showing the 10-degree tile display, and used on the website
One current problem with this product is that terrain shadow tends to build up over the 14 days, in mountainous regions, thus littering such regions with incorrect surface and flood water indications. Please keep this in mind when interpreting values over mountains. Terrain is generally indicated by the background in the MFM png product.
XTRA: Extra information, currently only used to denote vector products, but also available for special run variants.
V: Vector product.
V2: Vector product, filtered with 2 pixel sieve before vectorization (not currently produced).
.tif, .evf, .png, .shp, .kmz, .zip: appropriate format extension. Shapefiles are zipped for distribution.
Currently these are only distributed as vector products: shapefiles and KMZ files. MSW gives all land-based water (with a buffer into oceans) that was observed in the given product. MFW removes from MSW a reference or expected water layer, such that the remaining water is likely flood.
Polygons in the files represent flood or surface water areas, respectively. MFW polygons have attributes giving polygon size (in km2), and centroid.
There is no indication provided of where there is insufficient clear data in the given product to determine water extent. Thus, these products only indicate where water is likely to be, but the absence of a water polygon cannot be interpreted to mean there was no water present in a given area; it may simply have been sufficiently cloudy over the composite period for the required number of water observations (the Y in the composite indicator XDYO).
The MWP product (below) attempts to address this deficiency, and may eventually replace MFW and MSW.
These vector products can also be extremely resource intensive to generate from the source raster; a partly cloudy scene over water, or a tile over mountains with terrain shadow issues, can have tens of thousands of polygons, if we were to convert to shapefile or KMZ. Thus, we typically skip vector product generation if the number of polygons is greater than 20000.
At times, conversion of the shapefile product to KMZ product will also fail.
Introduced March 2012. Currently delivered only in geotiff raster format, with the following pixel values:
0 : Insufficient data to make water determination (cloudy, missing images, swath gaps swaths, or bad data values).
1 : No water detected.
2 : Water detected AND coinciding with reference water (e.g., not flood).
3 : Water detected, beyond reference water, so is likely flood.
To display all surface water (eg., MSW), use all pixels >= 2.
We may also begin distributing a vector product derived from MWP, if there is sufficient user interest.
This is simply the annotated 10x10 degree PNG graphic displayed on the website.
Note: Due to the zoomed out scale necessary to display an entire 10x10 degree tile, relatively small areas of flood or surface water will not be visible; this product is NOT full resolution!
Cloudiness is determined from the "confident cloudy" flag in the 1 km resolution MOD35 cloud product. However, this product often over predicts cloud cover of relevance to our product. Thus, at times, we are able to detect water under areas that MOD35 indicates are "confident cloudy". This is sometimes the case because dark water under thin clouds still appears dark enough to trigger the water detection algorithm. At other times, it occurs because the 1 km MOD35 cloud indicator is simply not sufficiently accurate spatially.
For all products, we keep all water detections, irregardless of MOD35, but do use MOD35 in deriving the "insufficient data" layer, along with areas of no data. Thus, at times, the relevant products may show surface or flood water entirely surrounded by "insufficient data" 0 values.
Although a more accurate 250 m cloud product would be preferable, at this point, MOD35 is the best available.
Shadows appear spectrally quite similar in MODIS bands 1 and 2 to dark water. Thus, our water detection algorithm flags most cloud shadows as water. To avoid this, the standard 2D2O and 3D3O products require multiple water observations (2 or 3, respectively) to flag a pixel as water. This greatly reduces the number of cloud shadows that would otherwise show up as water. Using both Aqua & Terra can also reduce to some degree the terrain shadows, since they provide morning vs afternoon illumination conditions. However in winter in mountainous terrain, there is often substantial number of pixels misidentified as water due to long winter shadows.
As of version 4.4, we have implemented a terrain shadow masking algorithm that predicts terrain shadows and removes any water pixels that fall under the predicted shadows. Due to limitations in our input data and processing requirements, the current solution is not perfect, and does not remove all terrain shadows, but does reduce their impact, at times substantially. We are working on improvements.
As of version 4.7, we have implemented an initial cloud shadow masking algorithm, that predicts cloud shadows based on viewing and solar geometry, cloud locations from the MOD35, and cloud height from MOD06 (cloud top temperature, interpolated to a standard atmospheric profile). Due to the coarse spatial resolution of MOD35 and MOD06, the resulting predicted cloud shadows have to be buffered out some distance to capture most shadows. However, the resulting mask may still miss shadows from clouds that were not identified in the MOD35 cloud product. It also suffers errors from the assumption of a standard atmospheric profile for determining cloud top height. For these reasons, it has generally been found detrimental to apply cloud shadow masking to multi-day products, because many real water observations can be masked due to the buffering required, and the purely compositing procedure generally does a very good job of removing shadows. The compositing approach does fail when cloud shadows recur in the same place over the 2 (or 3) day period - an occasional (if infrequent) situation. For single-day products, applying the cloud shadow mask is worthwhile because single-day products otherwise can contain large numbers of false positives in cloudy situations. We are working on improvements.
Both methods may actually remove real surface water from the products, if either (1) there is water on the surface and it is coincident with predicted terrain or cloud shadow, or (2) the terrain or cloud shadow predictions incorrectly mark areas as under shadow.
Although we allow water detections under what MOD35 declares as cloud, we cannot do so for areas where we have predicted cloud shadows. If those shadow predictions are excessively large (as they currently are due to the buffering we need to do, as mentioned above), this effectively reduces the surface area from which we are able to detect water, beyond that which a perfect cloud shadow prediction would require.
Note that both methods then classify sets of pixels as indeterminate because if they are under shadow, we cannot assess surface water conditions. In the MWP and MFM products, more pixels will thus appear as "insufficient data" if there are not the required number of "clear" images of that pixel available, because a "clear" condition will now require there be no shadows (along with no clouds).
The current MOD44W reference water is not optimal because it is seasonally static and in places out of date (some indicated lakes no longer exist while others have been formed), and thus does not reflect normal seasonal lake and river water height variations.
We are currently developing an ephemeral water layer, that will be used to identify unusual flood events from occurring within areas often flooded, over the past decade.
Lakes and rivers with a high sediment load, which may appear chalky blue or muddy brown in visible imagery, is usually not detected as water by the current algorithm. This is a fundamentally difficult issue because such water bodies spectrally appear quite similar to certain types of uninundated land surface.
For now, please note that flooding resulting in optically 'bright' water may not be detected in these products.