The Global Imagery Browse Services (GIBS) are designed to deliver global, full-resolution satellite imagery to users in a highly responsive manner, enabling interactive exploration of the Earth. To achieve that interactivity, GIBS first ingests imagery from a given NASA data provider on a continuous basis, creates a global mosaic of that imagery, then chops the mosaic into an image tile pyramid (see figure at right). By pregenerating these tiles, it relieves the servers of image rescaling and cropping duties, greatly reducing computational overhead and enabling a highly responsive system. This also means that the primary method of imagery retrieval for clients is tile-based. For more background on how tiled web maps work, see the MapBox Developers Guide.
An image tile pyramid (from OGC WMTS 1.0.0 specification)
While the requests made to GIBS are for individual tiles, users generally work at a higher level and configure a map library, GIS client, or script to determine which tiles to retrieve. These clients and scripts need to know which products are available, which map projections are available, and how many zoom levels they support. GIBS provides this access through four mechanisms:
The implementation of these services is built from the long-running "OnEarth" server system at NASA/JPL.
Access to GIBS via OGC WMTS, Tiled WMS, KML files, and GDAL is described below.
In addition, source code for the GIBS tiled imagery server and tiled imagery storage format is available. See this blog post for more info along with the code on GitHub.
In the list of available GIBS products, note that there are columns for "Projection(s)" and "Resolution". The currently available projections are:
Not all products are generated in all projections, though most products are available in at least "lat-lon" and Web Mercator. See the GIBS available product list to determine which projections are supported for each product. Please also note that there is a 1-4 hour delay in processing incoming imagery in the Web Mercator projection compared to that in the lat-lon / geographic projection.
For each of those projections, a certain number of zoom levels are available for each product. Again, the product list shows the maximum resolution available for each product. See below for a mapping of resolutions to zoom levels for each projection. This information can be used to configure your map client to work with GIBS.
For reference, the area/extent displayed in the polar projections were selected to a) cover the main land/ice masses at each pole and b), to ensure that the full resolution image has a resolution and pixel height/width that are a power of two as required by our tiled imagery storage system.
The Open Geospatial Consortium (OGC) Web Map Tile Service (WMTS) provides a way for clients to retrieve tiled mapping data in a standardized manner, handling product-specific details such as available number of zoom levels, map projections, image formats, tile sizes, etc. The WMTS specification provides guidance for three methods of tile retrieval: Key-Value Pair (KVP), REpresentational State Transfer (REST), and Simple Object Access Protocol (SOAP). GIBS supports KVP and REST.
The WMTS specification requires that a WMTS server provide information regarding the available imagery via a GetCapabilities request. Here is a list of available service endpoints, projections, and their GetCapabilities request:
The core concept within the GetCapabilities response is an imagery layer. The GIBS tiled imagery provides a unique global image per day per layer. Therefore, the layer definition within the GIBS GetCapabilities response must address a time dimension. The GIBS team has chosen to address this in the following manner, within each layer:
<Dimension> <ows:Identifier>time</ows:Identifier> <UOM>ISO8601</UOM> <Default>2013-05-29</Default> <Current>true</Current> <Value>2012-05-08/2013-05-29/P1D</Value> </Dimension>
(Note: “2013-05-29” will be replaced by the current UTC date.)
The parts of the Dimension data structure are taken from the WMTS 1.0.0 spec (Table 9, p. 22). However, since the WMTS spec doesn't address the time dimension (other than the use of "Current"), we are adapting some aspects of the WMS spec regarding the time dimension, specifically:
If the time dimension is omitted in the WMTS request, tiles for the current UTC date will be returned. Be aware that many of the current date’s tiles will be empty because the imagery is generated as the satellites orbit from east to west.
GIBS has chosen to implement the Key-Value Pair and RESTful service interfaces. Equivalent sample requests are included below:
More generically, the RESTful request follows the form of:
The WMTS RESTful interface above can be easily adapted for use as a "generic" XYZ tile server if the developer pre-populates all of the required fields except the tile row, column, and zoom level. For example, by starting with the most generalized GIBS API request:
Populating the fields with the desired projection, product, time, etc (Terra/MODIS Aerosol Optical depth from 2014/04/09, in this case), GIBS products can be used by clients such as ESRI's ArcGIS Online to add a "Tile Layer" by leaving the row, column, and zoom level as parameters:
Tiled WMS offers fast response to a limited number of WMS access patterns - specifically those access patterns which provide geographic bounds which fall along the edges of pregenerated tiles.
Those patterns are described in the TWMS GetTileService request. The response is an XML encoded list of available WMS access patterns. A TiledPattern access pattern is a set gridded WMS requests, where parameter order, case and content are constant, with the exception of the bbox values. Using this pattern allows fast access to tiles for a given combination of layers and associated styles at a given resolution over a defined area. All the information about a pattern can be extracted form the provided WMS call, using these rules:
Server prefix is defined in the OnlineResource tag Area covered is defined in the LatLonBoundingBox Tile size is provided by the width and height parameters values Tile format is provided by the format parameter value Tile coverage can be computed as (Lon1-Lon0)and (Lat1-Lat0), where Lon1,Lon0,Lat1 and Lat0 are the arguments of the bbox parameter. The Grid alignment results from the bbox argument and the tile coverage. The bbox argument values provided in the pattern are for the top-left tile, the other tile locations can be computed based on the tile coverage. Other metadata that might be of interest to a user is contained in the Name, Title andAbstract tags.
Multiple WMS patterns in a single TilePattern are equivalent. TilePattern tags that have something in common are grouped in a hierarchical structure build using TiledGroup tags. The innermost level refers to the same exact data, possible differences being the image size, image format, resolution, and alignment. Higher level TiledGroup are used to group together related datasets.
A client application is expected to request this information only if it is defined as a request in the WMS server Capabilities. Once obtained, the application needs to analyze the patterns, decide which ones can be used and then issue only WMS requests that match the pattern to the normal WMS server, requests that can be built by modifying the bbox argument in a TiledPattern and prefixing the resulting string with the content of the OnlineResource tag.
The 'time' parameter follows the form YYYY-MM-DD which should be included in the request for a time-varying layer; if the time dimension is omitted in the TWMS request, tiles for the current UTC date will be returned. Be aware that many of the current date’s tiles will be empty because the imagery is generated as the satellites orbit from east to west.
Google Earth KML files can be generated on-the-fly for all tiled products served by GIBS. The returned KML file contains NetworkLinks to the GIBS server - this means that when the KML file is loaded within Google Earth, a full globe's imagery is available, though only the relevant tiles are retrieved based on your current viewpoint. In short, the KML file directly maps data access to the Tiled WMS request patterns.
Service Endpoint
GIBS KML files are dynamically generated based on parameters passed to the GIBS "kmlgen" CGI script:
The acceptable values for layername can be found here. The time parameter supports a single day (YYYY-MM-DD) or repeating interval (Rx/YYYY-MM-DD/PyYmMdD), as specified by the ISO 8601 specification, where:
Sample executions
Example clients
Users can write scripts to download GIBS imagery programmatically via the Tile Map Specification (TMS) Minidriver for the Geospatial Data Abstraction Library (GDAL).
Create a local service description XML file and invoke gdal_translate. In this example, GIBS_Aqua_MODIS_true.xml is used to generate a true color JPEG image from Aqua MODIS of a smoke plume from western fires over the central United States. The contents of GIBS_Aqua_MODIS_true.xml would be:
<GDAL_WMS> <Service name="TMS"> <ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg4326/best/MODIS_Aqua_CorrectedReflectance_TrueColor/default/2013-08-21/250m/${z}/${y}/${x}.jpg</ServerUrl> </Service> <DataWindow> <UpperLeftX>-180.0</UpperLeftX> <UpperLeftY>90</UpperLeftY> <LowerRightX>396.0</LowerRightX> <LowerRightY>-198</LowerRightY> <TileLevel>8</TileLevel> <TileCountX>2</TileCountX> <TileCountY>1</TileCountY> <YOrigin>top</YOrigin> </DataWindow> <Projection>EPSG:4326</Projection> <BlockSizeX>512</BlockSizeX> <BlockSizeY>512</BlockSizeY> <BandsCount>3</BandsCount> </GDAL_WMS>
gdal_translate -of GTiff -outsize 1200 1000 -projwin -105 42 -93 32 GIBS_Aqua_MODIS_true.xml GreatPlainsSmoke1.tif gdal_translate -of JPEG GreatPlainsSmoke1.tif GreatPlainsSmoke1.jpg
In very limited testing, our experience has been that better image quality is obtained by using the GeoTIFF output format from the GDAL WMS, then converting this to other formats, if desired, using a second gdal_translate command, or other programs such as ImageMagick convert.
Invoke gdal_translate with the content of the local service description XML file embedded into the command. This approach is useful for automated scripting to download various layers, dates, etc. To generate the same image as above:
gdal_translate -of GTiff -outsize 1200 1000 -projwin -105 42 -93 32 '<GDAL_WMS><Service name="TMS"><ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg4326/best/MODIS_Aqua_CorrectedReflectance_TrueColor/default/2013-08-21/250m/${z}/${y}/${x}.jpg</ServerUrl></Service><DataWindow><UpperLeftX>-180.0</UpperLeftX><UpperLeftY>90</UpperLeftY><LowerRightX>396.0</LowerRightX><LowerRightY>-198</LowerRightY><TileLevel>8</TileLevel><TileCountX>2</TileCountX><TileCountY>1</TileCountY><YOrigin>top</YOrigin></DataWindow><Projection>EPSG:4326</Projection><BlockSizeX>512</BlockSizeX><BlockSizeY>512</BlockSizeY><BandsCount>3</BandsCount></GDAL_WMS>' GreatPlainsSmoke2.tif gdal_translate -of JPEG GreatPlainsSmoke2.tif GreatPlainsSmoke2.jpg
For both options, the information needed to create the local service description XML can be found in the large table on the GIBS Available Imagery Products page.
Items that may need to be changed include:
1) <ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg4326/best/layer_name/default/date/resolution/${z}/${y}/${x}.format</ServerUrl>
layer_name - use "Layer Name on Server" from Products page. Note that only one layer can be retrieved per gdal_translate call.
date - use the desired date in YYYY-MM-DD format
resolution - use the appropriate EPSG code from Footnote 4 on the GIBS Available Imagery Products page and the "Resolution" in the format ####m or GoogleMapsCompatible_Level# resolution
format - use jpg or png extension based on the "Format"
2) Bounding box - use -180.0, 90, 396.0, -198 for Geographic projection and -4194304, 4194304, 4194304, -4194304 for the Polar projections. This is the bounding box of the topmost tile, which matches the bounding box of the actual imagery for Polar but not for Geographic.
3) <TileLevel> - select from the table below based on "Resolution" and "Projection"
Resolution | TileLevel (Geographic) | TileLevel (Polar) |
---|---|---|
2km | 5 | 2 |
1km | 6 | 3 |
500m | 7 | 4 |
250m | 8 | 5 |
31m | 11 | - |
4) <TileCountX><TileCountY> - use 2, 1 for Geographic projection and 2, 2 for Polar projections
5) <Projection> - use the appropriate EPSG code from Footnote 4 on the GIBS Available Imagery Products page.
6) <Bands> - use 3 for .jpg (except use 1 for ASTER_GDEM_Greyscale_Shaded_Relief) and 4 for .png
Note that the values for <YOrigin>, <BlockSizeX>, and <BlockSizeY> are constant for all GIBS layers.
In this example, GIBS_OMI_AI.xml is used to generate a transparent PNG image from the OMI Aerosol Index over the same region as the first two examples. The "Layer Name on Server" and EPSG/resolution in <ServerURL>, the <TileLevel>, and the <BandsCount> have changed from the first examples. The contents of GIBS_OMI_AI.xml would be:
<GDAL_WMS> <Service name="TMS"> <ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg4326/best/OMI_Aerosol_Index/default/2013-08-21/2km/${z}/${y}/${x}.png</ServerUrl> </Service> <DataWindow> <UpperLeftX>-180.0</UpperLeftX> <UpperLeftY>90</UpperLeftY> <LowerRightX>396.0</LowerRightX> <LowerRightY>-198</LowerRightY> <TileLevel>5</TileLevel> <TileCountX>2</TileCountX> <TileCountY>1</TileCountY> <YOrigin>top</YOrigin> </DataWindow> <Projection>EPSG:4326</Projection> <BlockSizeX>512</BlockSizeX> <BlockSizeY>512</BlockSizeY> <BandsCount>4</BandsCount> </GDAL_WMS>
gdal_translate -of GTiff -outsize 1200 1000 -projwin -105 42 -93 32 GIBS_OMI_AI.xml GreatPlainsSmokeAI.tif gdal_translate -of PNG GreatPlainsSmokeAI.tif GreatPlainsSmokeAI.png
In this example, GIBS_Terra_MODIS_Arctic.xml is used to generate a true color JPEG image from Terra MODIS of a phytoplankton bloom in the Barents Sea. The "Layer Name on Server" and EPSG/resolution in <Serverurl>, the <DataWindow> elements, and the <Projection> have changed from the first examples. The contents of GIBS_Terra_MODIS_Arctic.xml would be:
<GDAL_WMS> <Service name="TMS"> <ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg3413/best/MODIS_Terra_CorrectedReflectance_TrueColor/default/2013-08-01/250m/${z}/${y}/${x}.jpg</ServerUrl> </Service> <DataWindow> <UpperLeftX>-4194304</UpperLeftX> <UpperLeftY>4194304</UpperLeftY> <LowerRightX>4194304</LowerRightX> <LowerRightY>-4194304</LowerRightY> <TileLevel>5</TileLevel> <TileCountX>2</TileCountX> <TileCountY>2</TileCountY> <YOrigin>top</YOrigin> </DataWindow> <Projection>EPSG:3413</Projection> <BlockSizeX>512</BlockSizeX> <BlockSizeY>512</BlockSizeY> <BandsCount>3</BandsCount> </GDAL_WMS>
GeoTIFF files created by GDAL in the GIBS polar projections do not work correctly due to a bug in the GDAL GeoTIFF library. There are several workarounds for this:
1) Use a ".aux.xml" file with the ".tif" file. Download the sample Arctic or Antarctic XML file and rename it to match the GeoTIFF file.
gdal_translate -of GTiff -outsize 980 940 -projwin 1520000 240000 2500000 -700000 GIBS_Terra_MODIS_Arctic.xml BarentsSea.tif "copy" GIBS_Arctic_3413.tif.aux.xml "to" BarentsSea.tif.aux.xml gdal_translate -of JPEG BarentsSea.tif BarentsSea.jpg
2) Use JPEG format instead. This will create a .jpg.aux.xml file in addition to the .jpg file.
gdal_translate -of JPEG -outsize 980 940 -projwin 1520000 240000 2500000 -700000 GIBS_Terra_MODIS_Arctic.xml BarentsSea.jpg
3) Force the output SRS using the Arctic or Antarctic PROJ4 definitions.
gdal_translate -of GTiff -outsize 980 940 -a_srs "+proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs" -projwin 1520000 240000 2500000 -700000 GIBS_Terra_MODIS_Arctic.xml BarentsSea.tif gdal_translate -of JPEG BarentsSea.tif BarentsSea.jpg
In this example, GIBS_Aqua_MODIS_Arctic.xml is used to generate a true color JPEG image from Aqua MODIS of the Beaufort Sea reprojected to have 145W down. The "Layer Name on Server" and EPSG/resolution in <Serverurl>, the <DataWindow> elements, and the <Projection> have changed from the first examples. The contents of GIBS_Aqua_MODIS_Arctic.xml would be:
<GDAL_WMS> <Service name="TMS"> <ServerUrl>http://gibs.earthdata.nasa.gov/twms/epsg3413/best/MODIS_Aqua_CorrectedReflectance_TrueColor/default/2013-06-20/250m/${z}/${y}/${x}.jpg</ServerUrl> </Service> <DataWindow> <UpperLeftX>-4194304</UpperLeftX> <UpperLeftY>4194304</UpperLeftY> <LowerRightX>4194304</LowerRightX> <LowerRightY>-4194304</LowerRightY> <TileLevel>5</TileLevel> <TileCountX>2</TileCountX> <TileCountY>2</TileCountY> <YOrigin>top</YOrigin> </DataWindow> <Projection>EPSG:3413</Projection> <BlockSizeX>512</BlockSizeX> <BlockSizeY>512</BlockSizeY> <BandsCount>3</BandsCount> </GDAL_WMS>
gdalwarp -t_srs '+proj=stere +lat_0=90 +lat_ts=70 +lon_0=-145 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs' -te -1600000 -2500000 1200000 -400000 -tr 1000 1000 GIBS_Aqua_MODIS_Arctic.xml Beaufort_neg145down_1km.tif gdal_translate -of JPEG Beaufort_neg145down_1km.tif Beaufort_neg145down_1km.jpg
More information on GDAL_WMS can be found here (note the "TMS" section).
A "Bulk Download" is defined as the planned retrieval of more than 1,000,000 imagery tiles within a 24 hour period. These activities are typically orchestrated through script-based access to the GIBS API, not user-based access through a client application. In order to ensure quality of service for all GIBS users, the GIBS team requests that bulk downloading activities be coordinated at least 48 hours in advance of the planned download. Prior to beginning your bulk downloading activities, please contact the GIBS support team at support@earthdata.nasa.gov with the subject "GIBS Bulk Download Request" and the following information:
The GIBS utilization profile indicates that there is not a period of time within which "regular" usage drops. Therefore, bulk downloading activities are allowed to occur as is convenient for the downloading group or individual. The following guidelines should be taken into consider when designing a bulk download plan:
Subscribe to our mailing list and follow our blog to stay up-to-date with new features and changes to existing services. Or contact us at support@earthdata.nasa.gov with feedback and questions.