A Web service is a software system designed to support interoperable machine‐to-machine interaction over a network. Web services use Extensible Markup Language (XML) syntax to construct their messages. The advantages of an XML-based Web service architecture include the following:

  • platform independence
  • physical location independence (i.e., where the message is being sent from)
  • application language independence
  • client's knowledge independence (i.e., what kind of processor the server uses)

Web services use Hypertext Transfer Protocol (HTTP) as the underlying communication protocol that facilitates how applications send XML messages to Web services. Representational State Transfer (REST) and Simple Object Access Protocol (SOAP) comprise messaging protocols to exchange structured information to implement web services within a network.

The LAADS DAAC currently offers a handful of Web services that more experienced users can use to programmatically access and retrieve their desired data products. They include a few that qualify as open standards (OGC, WCS, and OPeNDAP) and an In-house Application Programming Interface (API), LAADS Web Services. An API allows two applications to interact with each other without any user intervention. They facilitate communication between one set of products or services with another set while remaining agnostic regarding implementation details.

What you should know before you use any of the following three web services:

  1. A critical detail that users should keep in mind while using these Web services relates to the Collection vs. Archive set distinction that is described above in the LAADS Online archive tutorial. To recap, the collection number reflects the version ID of the current production cycle for a certain product while the archive set number points to an archive storage detail. The mapping between these two attributes is what the above table provides. When you develop your API for all three Web services, the URL requires a collection=value parameter for some cases — always set the value to “ArchiveSet.”
  2. You should use a client that understands both how to make a request to the service and how to process the results of that service.
    • All services provide documentation on how to write a client, while some services already have clients that support making a request to the service and processing its results.
    • All services respond to HTTP requests from web browsers.
  3. Each of the following web services have unique capabilities, and users should consider when and why they may want to use each of them. Each individual section includes some general pointers to aid users in their decision as they consider its use.

Open Geospatial Consortium (OGC) – Web Coverage Service (WCS)

OGC’s WCS standard enables Web-mediated retrieval of coverages. A coverage is a digital representation of a spatio-temporal object that usually comprises the content of a geographic information system (GIS) process or service. The MODAPS WCS API follows the OGC WCS API, although our implementation (at version 1.0) does not conform to the latest version of the standard, which is now at version 2.1. Users would require an XML parser to process the output of the service. Some GIS tools (for instance ESRI tools and those based on GDAL library) can understand the protocol. Like the benefits from other Web services, this service provides the ability to directly stream filtered, subsetted, reformatted and regridded data that conform to user specifications.

MODAPS WCS API that provides access to MODIS Level-1 and Atmosphere data products

OGC’s WCS Standard

OpenAPI for Coverages — GitHub

Open-source Project for a Network Data Access Protocol (OPeNDAP)

OPeNDAP is a data transport architecture and protocol used in the earth science modeling, research, and applications communities. OPeNDAP was designed and implemented to provide researchers universal access to science data products using the same client/server model provided by the World-Wide Web and the Internet. Clients can submit specifically tailored requests to web servers supporting web pages that handle and manage the science data products. Client-specified requests for datasets conforming to a certain format, space-time, or variable-subset are directly delivered to the requesting client.

OPeNDAP provides a data server architecture that provides access to data stored on remote servers that end-users can access and use within their own client software. See a list of all the available OPeNDAP client software and their libraries. OPeNDAP data requests are submitted via URLs; the URL’s syntax contains all the elements, i.e., product name, science dataset or variable name, spatial and temporal details for the requesting action, etc. A major advantage of OPeNDAP is the ability to perform data filtering, subsetting, and data format transformation operations directly from the client. OPeNDAP is limited in its ability to conduct searches and cannot search by area of interest.

All the publicly available LAADS DAAC product collections are available via OPeNDAP

For additional information about OPeNDAP, check the following sources:

OPeNDAP User Guide from the OPeNDAP organization

NASA Earthdata OPeNDAP User Guide

How to use OPeNDAP to access data – video tutorial from NASA JPL PO.DAAC

OPeNDAP URL syntax examples that demonstrate how to download particular LAADS datasets:

  1. Download Aqua-MODIS MYD04_3K, Collection-6.1 product from year 2015, day 130, time 0800 in netCDF
  1. Download SNPP-VIIRS VNP02IMG, Collection-1 product from year 2015, day 40, time 0512 in ascii
  1. Download Terra-MODIS MOD03, Collection-6 product from year 2013, day 56, time 0000 in netCDF:
  1. Download Terra-MODIS MOD03, Collection-6 product from year 2013, day 56, time 0000 in ASCII format:
  1. Download Terra-MODIS MOD03, Collection-6 product from year 2013, day 56, time 0000 in netCDF but only include the Scan_Offset variable in a range from 0 to 4059 with a stepping of 1 in the first dimension, and a range of 0 to 2707 with a stepping of 1 in the second dimension.

In-house API – LAADS Web Service (LWS) Classic

LWS Classic is an in-house-developed, custom SOAP- and REST-based API that allows users to search, order, and download MODIS and VIIRS Level-1 and higher-level atmosphere data products through a programmable interface. It requires an XML parser to process the output of the service. It provides extensive search capabilities, and the standard set of data transformation functions. It does, though, require extra steps to order and poll for completion, or directly download subsetted, reformatted, and regridded data. Consult the following links for additional information:

LWS Classic Quick Start Guide

LWS Classic API

Last updated: November 9, 2021