ECHO Data Partners

Overview

Data Partners provide the ECHO community with metadata representing their Earth Science data holdings. Client applications have access to data holdings via order distribution or online access. Data Partners retain complete control over what metadata is represented in ECHO including inserting new metadata, modifying existing metadata and removing old metadata. Data Partners may also establish data access restrictions to control the availability of sensitive data holdings.

The information contained within the Data Partners section of this website is organized to support the efforts of new and current ECHO Data Partners. View a complete list of current ECHO Data Partners.

Data Partner Responsibilities

Data partners are responsible for:

  • Regularly generating XML metadata according to the ECHO format

Generating Metadata

Generating Metadata

Tip: To download an xsd or dtd file, right-click and select "Save Link As..."

Overview

The topics covered on this page include information regarding the generation of metadata files in the Extensible Mark-up Language (XML) format. These metadata files are used to describe additions, removals, and changes to a provider's data holdings. It is the responsiblity of the Data Partner to regularly publish metadata reflecting the ongoing changes to its Earth Science data.

The information provided is broken up into the following topic areas:

  • Metadata Organization - Brief description of the major metadata constructs.
  • ECHO 10.0 Schemas - Current XML Schemas used for validation of submitted metadata.
  • Requirements & Recommendations - A description of the minimum metadata requirements and additional recommendations.
  • Special Considerations - Highlighted topics regarding metadata generation of which Data Providers should be aware.

Metadata Organization

Data providers are responsible for generating metadata files in the (XML) format that comply with the published ECHO Data Model. The following two metadata constructs are utilized by the ECHO system:

  • Collection - A grouping of science data that all come from the same source, such as a modeling group or institution. Collections have information that is common across all the granules they contain and a template for describing additional attributes not already part of the metadata model.
  • Granule - The smallest aggregation of data that can be independently managed (described, inventoried, and retrieved). Granules have their own metadata model and support values associated with the additional attributes defined by the owning collection.

Data Providers may generate a full metadata record which will be processed as an insert or full replacement. Providers may generate metadata to update or delete specific fields within a metadata record. Providers may also generate metadata to delete an entire metadata record from ECHO.

Note that deleting a collection will cascade to delete all associated granules. However, a cascaded or explicit granule deletion will not cascade to delete associated browse records.

For a complete overview of metadata organization, please refer to section 3 of the ECHO 10.0 Data Partner User's Guide

ECHO 10.0 Schemas

Metadata submitted by new ECHO partners must conform to the following XML Schema that corresponds to the particular messages involved. These schemas are subject to change through regular ECHO releases. For more information regarding upcoming changes, contact ECHO Operations at echo@echo.nasa.gov or view the following links which refer to the mode-specific Ingest documentation for Ingest Schemas, DTDs, and sample metadata files.

  • Operations Ingest Schemas, DTDs, & Sample Metadata - (HTML)
  • Partner Test Ingest Schemas, DTDs, & Sample Metadata - (HTML)
  • Testbed Ingest Schemas, DTDs, & Sample Metadata - (HTML)

Requirements and Recommendations

The ECHO Data Partner's User Guide outlines the ECHO metadata requirements and recommendations for metadata Ingest into the ECHO system. For each metadata type, the minimum metadata fields required to validate against the ECHO Ingest schema are outlined. In addition to this, we have provided a list of recommended metadata fields that should be included in data Ingested into ECHO. These additional fields will facilitate the searching and ordering of data by the Earth Science community.

Special Considerations

The following items outline some common areas which Data Partners should be aware of while generating their metadata. For a complete overview of ECHO Ingest Business Rules, please refer to:

Dates and Times

Providers utilizing the ECHO 10.0 XML schema format must conform to the XML Schema Specification. Providers utilizing the ECHO 8.0/9.0 DTD format must coordinate with ECHO Operations to define a provider-specific format to be used for all dates and times in generated metadata. Unless otherwise specified in the provided date/time value, ECHO will process all date and time fields in the GMT timezone.

Temporal Ranges

The collection and granule metadata both contain temporal ranges for the associated item. If a collection specifies a temporal range, ECHO will verify that each ingested granule falls within the specified range. If a collection does not specify a temporal range, then the verification will be skipped. If a provider performs a collection update to modify the temporal range, and granules exist in ECHO which invalidate the new range, the update will be rejected.

Spatial Types

ECHO supports three spatial data types (Orbit, Global, Geometry). Within the Geometry spatial type, ECHO supports both the Geodetic and Cartesian coordinate systems. Spatial information can be associated with collections and granules, however the data types do not need to be the same. A collection's spatial representation specifies how the extent of the entire collection will be specified. A granule's spatial representation specifies how the extent of each granule will be specified.

For example, a collection may have a spatial type of Global to designate that data within that collection will cover the whole earth. However, the associated granule's spatial type may be Cartesian to designate that each granule's spatial coverage will be described with points on the Cartesian coordinate system.

ECHO's holdings are contained within an Oracle database and must conform to the restraints inherent in the Oracle spatial model (for more information see Oracle's Spatial User's Guide and Reference). Existing spatial restrictions within ECHO include the following list. For a full listing of restrictions, see the Data Partner's User's Guide.

  • A spatial area specified in the Geodetic coordinate system cannot cover more than half of the earth.
  • A spatial area specified in the Cartesian coordinate system cannot cross the international dateline.
  • Geometric points must be specified in a clockwise direction.

Unique Values

ECHO requires specific metadata fields in order to uniquely identify collection, granule, and browse records within its holdings. These fields are validated for uniqueness during ingest and used during updates, replacements, and deletions in order to uniquely a target record. The fields which are validated for uniqueness are found below.

  • Collection - DatasetID
  • Collection - ShortName and VersionID
  • Collection - LongName
  • Granule - GranuleUR
  • Browse - ProviderBrowseId

Metadata Inheritance

Specific metadata fields have been designated to require an enforced 'inheritance' validation between collections and associated granules. This means that values for these fields which are specified at the collection level include a superset of all values which may be specified at the granule level. For example, if a collection specifies Campaigns A, B, and C, all associated granules may have any subset of these campaigns. However, if a granule specifies a Campaign D, it will be rejected. Collection and granule updates will always perform this validation check to ensure the inheritance is valid. Affected fields include the following:

  • Campaign
  • Platform
  • Instrument
  • Sensor
  • Additional Attributes
  •  Monitoring the ingest of submitted metadata to ensure ECHO holdings are current with each provider's holdings.

Ingesting Metadata

Ingesting Metadata

TipTo download an xsd file, right-click and select "Save Link As..."

Overview

The term "Ingest" refers to the process by which ECHO loads published metadata files into its metadata holdings for the usage of the ECHO user community. The term "Ingest job" refers to a distinguishable grouping of submitted metadata files which are processed and reported upon by ECHO Ingest.

The topics covered on this page include information regarding the metadata Ingest process performed by ECHO. It is the responsiblity of the Data Partner to regularly monitor the Ingest of their published metadata.

The information provided is broken up into the following topic areas:

  • Ingest Workflow - An overview of how ECHO processes submitted metadata.
  • Ingest Reporting - An overview of the available methods for tracking the progress of active Ingest jobs and the results of completed jobs.
  • Ingest Policies - A listing of ingest related policies which Data Partners should be aware of.

Ingest Workflow

ECHO continually detects submitted metdata and will create Ingest jobs which are then processed. Each job is transformed and validated against the ECHO 10.0 metadata schema, and sorted according to metadata action type. After these steps, a job may wait for associated browse image files or proper sequencing. After the job is released from a waiting state, it is queued for loading. When the current Ingest job completes loading, Ingest will generate a ftp accessible Ingest report, notify the Data Partner, and begin loading the next queued job.

For a more detailed description of the internal ECHO Ingest states, please refer to:

  • Section 6 of the ECHO Ingest Supplementary Specification - (PDF)

Delivery Methods

Data Providers submit their metadata files to a configured ftp location on the ECHO system. The ECHO Ingest process regularly detects published metadata files and will bundle a group of detected files or a single package file into an Ingest job.

Providers may deliver metadata files in two ways:

  • Package Delivery - A single zip file containing metadata files and an xml manifest file describing the contents of the package.
  • Single File - Metadata files are submitted by themselves.

ECHO recommends Data Provider submit metadata using the package delivery method. This method allows providers to assign a textual job name (e.g. "Ingest Job #3 - 10/21/2008"), and a package sequence number. Each Ingest Job is associated with a sequence number in order to ensure metadata is submitted in the correct order. Providers are encouraged to utilize this mechanism by supplying their own package sequence numbers to manage the processing of their data.

For a more detailed description of metadata delivery methods, please refer to:

  • Section 3.2 of the ECHO Data Partner User's Guide - (PDF)
  • Package Manifest - (HTML) (XSD)

Processing Order

Each submitted metadata file will contain a specific type of metadata item (e.g. collection insert, granule partial update, etc...). In order to ensure that metadata items are ingested correctly, metadata actions are processed in the following order:

  1. Browse inserts/replacements
  2. Collection inserts/replacements
  3. Collection partial deletes
  4. Collection partial updates
  5. Collection deletes
  6. Granule inserts/replacement
  7. Granule partial deletes
  8. Granule partial updates
  9. Granule deletes
  10. Browse deletes

Last update usage. How does last update work for collection & granule partial update. How does last update work for browse (not required)

Ingest Reporting

Ingest reports its activity to Data Providers through email and automatically generated report files. These two reporting mechanisms are described below. For a more detailed description of metadata delivery methods, please refer to:

  • Section 3.14 of the ECHO Data Partner User's Guide - (PDF)
  • Ingest Report Schema - (HTML) (XSD)

Email Notifications

ECHO Ingest will notify a configurable list of individuals associated with each Data Provider when an ingest job is started and completed. The automatically generated email will include identifying information for the job and the event time. Note that when a job is 'started', this means that it has been added to the queue for a provider. Ingest will process received jobs according to the order of receipt, or sequence number (if provided). Emails will be generated for the following situations:

  • Start of Ingest job
  • Timeout waiting for browse image
  • Timeout waiting for sequenced package
  • Completion of Ingest job
  • ... Needs verification ...

Ingest Reports

When an ECHO Ingest job completes, an XML report file is generated and placed in the provider's ftp output directory. This file is created according to the schema referenced below.

The XML format used for the ECHO Ingest reports facilitates automated ingest processing and reconciliation. Each Ingest report includes the following information.

  • Job Errors - Errors which occur creating the job which result in the job not being processed.
  • Job Processing Totals - A count of collection, granule or browse insertions, updates, replacements, deletions, and rejections for the entire job.
  • File Processing Totals - A count of collection, granule or browse insertions, updates, replacements, deletions, and rejections for each metadata file.
  • File Errors - Errors which occur processing a metadata file which may result in a file not being processed.
  •  Item Errors - Errors which occur processing a metadata item which result in an item rejection.

ECHO Ingest Accounting Tool (EIAT)

Data Providers may use the ECHO Ingest Accounting Tool (EIAT) to monitor their active jobs and to the information included in the XML Ingest reports. A provider can view an overall summary of Ingest jobs being processed and the following information for the provider's Ingest jobs:

  • Detailed information for live Ingest jobs
  • Detailed information for completed Ingest jobs
  • Detailed information for rejected items during Ingest
  • Summary Report of completed Ingest jobs

To access EIAT, visit the following links. The ECHO authentication associated with each system will be used to allow access to users who have been granted "provider role" to an ECHO Data Provider.

ECHO Ingest Policies

The following policies outline a few guidelines for interacting with ECHO Ingest. Additional policies are outlined in the Data Partner's Operation Agreement, which is signed by both ECHO and the Data Partner. For questions regarding ingest policies, please contact ECHO directly at echo @ echo.nasa.gov.

  1. ECHO will retain original metadata and Ingest logs for a maximum of 60 days.
  2. ECHO will retain original browse image files for a maximum of 60 days.
  3. ECHO will remove all Ingest report files in the provider output area greater than 60 days old.
  4. ECHO will remove all reconciliation files in the provider output area greater than 60 days old.
  5. ECHO may configure a provider for manual ingest processing if problems are detected with submitted metadata.
  6. ECHO will not manually edit metadata within the ECHO DB to correct invalid data. Data Partners should resubmit metadata with the valid data values to correct such situations. 
  •  Managing accessibility to data with rules, conditions, permissions, and restrictions based on the data and/or the user community.

Managing Data

Managing Data

TipTo download an xsd file, right-click and select "Save Link As..."

Overview

The topics covered on this page include information regarding access management of data which has been ingested into the ECHO holdings. It is the responsiblity of the Data Partner to manage the availability of their datasets and properly restrict data to the user groups who should have access. All data management is performed through the ECHO API. ECHO providers an online tool, the Provider User Management Tool (PUMP), which facilitates all data management tasks which are performed by Data Partners.

For a more detailed description of data management actions, please refer to:

Section 5 of the ECHO Data Partner User's Guide - (PDF)

The information provided is broken up into the following topic areas:

  • Provider Role - A required privilege for a user to manage a provider's data.
  • User Groups - Logical groupings of ECHO users.
  • Access Control List (ACL) - Conditioned rules which are used to filter the viewing and ordering of provider metadata.
  • Restriction Flag - Metadata field used for restricting data.
  • Visibility - Basic access control method bypassing all other access rules.
  • Special Considerations - Highlighted topics regarding data management of which Data Providers should be aware.

To access the Provider User Management Program (PUMP) for data management activities, visit the following links:

Provider Role

In order to manage a Data Partner's access control, a user must be granted 'provider role' to the provider which they will be managing. The ECHO Operations staff, or another user with provider role, may grant this privilege to another user through PUMP. After the privilege has been granted, the privileged user may log into PUMP and will be presented with data management capabilities. A user may be granted 'provider role' to multiple providers, and will simply choose which provider they wish to manage after they have logged in.

User Groups

ECHO Users who have been granted 'provider role' can create and manage user groups within ECHO. These user groups are used to create logical groupings of ECHO users which can then be granted access to publically restricted data. Each user group must have at least one manager and member. Each manager can add or remove members and managers from the group. A user who does not have 'provider role' can manage an ECHO group, but does not have the capability to create or remove a group. All user group management can be performed through PUMP.

Access Control List (ACL)

Access Control List (ACL) rules are a list of conditioned rules which are used to filter the viewing and ordering of provider metadata. ACL management requires the 'provider role' privilege and can be performed through PUMP. An ACL rule has the following components:

Condition Type

Each rule has a specific condition which is used to determine whether the rule should be activated or not. Possible condition types are:

  • Boolean - Based on a condition which is true or false.
  • Restriction Flag - Based on the restriction flag metadata field.
  • Temporal - Based on a fixed start and end date/time.
  • Rolling Temporal - Based on a fixed duration (e.g. within the last 30 days).

Access Type

Each rule has a specific access type which specifies the action that will be taken if the rule is activated. Note that permitting access will override restricting access. Possible access types are:

  • Restrict - Hides data from all users in the system if the rule is matched.
  • Permit - Grants access to data if the rule is matched.

Action Type

Each rule has a specific action type which specifies the action that will be restricted or permitted the rule is activated. Note that users must be able to view a metadata record in order to order it. Possible action types are:

  • View - Restrict or permit the discovery of metadata records.
  • Order - Restrict or permit the order of metadata records.

User Group

Each rule which grants access to metadata can be assigned to zero or more ECHO user groups. Note that if you do not choose an ECHO user group, the ACL rule will permit access to all users, overriding *all* other rules.

Metadata Records

Each rule has a specific list of metadata records within a Data Provider's holdings to which a rule will be applied if the rule is activated. Possible metadata types are:

  • All Collections - The dynamic listing of all collections.
  • Selected Collections - A static listing of specific collections.
  • All Granules - The dynamic listing of all granules.
  • Selected Granules - A static listing of specific granules.

Restriction Flag

The restriction flag is a decimal value which is specified in a Data Partner's collection or granule metadata. Data Partners may use PUMP to configure an ACL which utilizes the restriction flag value within a record's metadata in order to determine visibility. The availability of data can then be changed during ECHO Ingest through the usage of partial updates or full metadata replacement. A granule or collection's restriction flag cannot be updated through the API.

Visibility

Data Partners may use PUMP to configure collections within ECHO to have a visibility of "OPEN" or "RESTRICTED". A visibility setting of OPEN will allow the collection to be viewable by all ECHO users according to any associated Access Control List (ACL) rules. A visibility setting of RESTRICTED will override all associated ACL rules. Data in this state will only be accessible through the ECHO API if a user logs in by specifically setting their context to the collection's provider. To do so, the user must have been granted 'provider role.'

The visibility flag is most useful for hiding datasets within ECHO while ACL rules and Option Definitions are configured. ECHO strongly enourages providers to use ACL rules in order to restrict access to data in an ongoing basis. The visibility flag should only be used as a temporary method of restricting access.

Special Considerations

The following items outline some common areas which Data Partners should be aware of while managing the access to their metadata.

WIST Valids Rule

A viewing permission rule must be created with the ECHO user group ECHO_Valids in order to allow a Data Partner's collections and granules to be accessible from WIST. WIST will not use this rule to allow access to data which should be restricted.

Autopopulate Rule

A viewing permission rule must be created with the ECHO_SYS user group in order to allow ECHO to complete autopopulation during ordering. If a Data Partner is not using the autopopulate functionality in the ECHO forms specification, then this rule does not need to be created. This is only a temporary solution to allow for autopopulation.

Default Collection Visibility

When a collection is inserted or replaced through ECHO ingest, the visibility is automatically reset to the value contained within the metadata. For Data Partners who are submitting metadata which requires translation to the ECHO 10.0 format, a default visibility is configured in ingest. This value is typically RESTRICTED, which means all collection inserts and replacements will restrict access. Providers should use PUMP to review and update collection visibility as needed.

Instantaneous Access Control

All changes in visibility, user groups, and ACL rules are applied as soon as they are updated in ECHO.

  •  Fulfilling orders by rejecting, accepting, canceling, and closing orders and quote requests.

Fulfilling Orders

Fulfilling Orders

Tip: To download an xsd file, right-click and select "Save Link As..."

Overview

The ECHO system acts as an order brokering service between end users and Data Partners. Users may submit orders for collections and granules that have been ingested into ECHO and marked as 'orderable.' ECHO will keep basic metrics and information regarding the order including the orderer's information, order contents, and historical order updates.

For a more detailed description of order fulfillment, please refer to:

  • Sections 6 & 7 of the ECHO Data Partner User's Guide - (PDF)

The information provided is broken up into the following topic areas:

  • Order Options - The mechanism by which a specific information is requested from a user at the time of ordering.
  • Forms Specification - The specific syntax and features utilized by ECHO Data Partners when creating an order option definition..
  • Order Fulfillment API - Ordering service which each Data Partner provides to fulfill orders submitted through ECHO.
  • Special Considerations - Highlighted topics regarding order fulfillment of which Data Providers should be aware.

To access the Provider User Management Program (PUMP) for order policy configuration and order tracking, visit the following links:

Operations - http://api.echo.nasa.gov/pump/
Partner Test - http://api-test.echo.nasa.gov/pump/
Testbed - http://testbed.echo.nasa.gov/pump/

Order Options

The term "order option" refers to the mechanism by which a Data Partner can request specific information from a user at the time of ordering. For example, an order option may require that users provide ftp-push information, or specific subsetting information. The ECHO Forms Specification defines the structure and content of the XML documents which are used in ECHO to specify the order options assigned to a collection within the ECHO data catalog. The term "ECHO Form" is used to refer to the XML document created using the standards in the ECHO Forms Specification.

It is the responsibility of the ECHO Data Partners to design, upload, and assign order options to their catalog items using the ECHO Forms Specification. If a provider's collection does not allow ordering, then an order option may not be assigned. It is also the responsibility of the Data Partner to verify that their order options correctly define the information needed to complete the order process.

It is the responsibility of an ECHO Client Partner which is offering the service of ordering ECHO data to implement functionality that will display the ECHO Form. It is strongly encouraged that a Client Partner implementing the ordering functionality ensure that the entire ECHO Forms Specification can be represented. ECHO Data Partners may choose to utilize any and all parts of the specification. If ordering is not a feature which is included in the scope of a Client Partner's work, then they need not implement the ECHO Forms Specification.

Provider vs System Level Forms

The ECHO Forms that are created and uploaded by Data Partner are referred to as "provider level forms." This designates the fact that they are visible only to the Data Partner who uploaded the form. There are also ECHO Forms that are created and uploaded by the ECHO Team, and they are referred to as "system level forms." These forms are visible to all providers. The purpose of system level forms is to centralize common option definition elements which can be shared by all providers in order to reduce duplication of form components.

Order Option Assignments

Within ECHO, an option assignment must be created between an option definition and collection in order to signifiy that order options exist during the ordering process. Multiple definitions may be assigned to a single collection, and a definition can be assigned to multiple collections. An option assigment may also include an Xpath statement which will filter on a granule's metadata to determine whether the granule should use the assigned option definition, or not.

ECHO Forms Specification

The ECHO Forms Specification, found below, outlines the complete set of syntax and features utilized by ECHO Data Partners when creating ECHO Forms. The specification also describes the workflow and user interface elements which are used as form controls. Also found below are links to the XML Schemas defining the ECHO Form's XML structure.

  • ECHO Forms Specification - (PDF)
  • Autopopulate XML Schema - (XSD)
  • ECHO Forms XML Schema - (XSD)

Sample Forms

In order to facilitate ECHO Forms development, some sample provider forms and the current ECHO system form are provided below. Also included is the ECHO Forms Sandbox webpage which may be used to display realtime forms processing.

  • Basic FTPPush/Pull & SCP Provider Level Form - (XML) (JPG) - This form which utilizes a very simple structure where the user has three distribution methods. Only the FTPPush option is shown in the image.
  • Basic Media & Relevancy Provider Level Form - (XML) (JPG) - This form which contains options for FTP Push, Pull, CD-ROM, DLT, or DVD media distributions. The provided image shows each media option resulting in different information prompted from the user. This form takes advantage of the 'relevancy' functionality of the forms to determine when or when not to display certain items.
  • Advanced FTPPush/Pull Provider Level Form - (XML) (JPG) - This form is similar to the xmlFTP_Media example, however it allows a user to enter subsetting information based upon spatial or parameter subsetting. This form takes advantage of an xpath constraint to enforce that the user choose a subsetting parameter scheme. Finally, you will see that this form uses the autopopulate capabilities of the ECHO forms specification to populate the size of the granule into the subsetting options.
  • Advanced FTPPush/Pull Provider Level Form - (XML) (JPG) - This form provides another example using relevancy, subsetting options, and the autopopulate capabilities.
  • System Level Order Option - (XML) - The current system level form provided by ECHO.
  • ECHO Forms Sandbox - (ZIP)

Order Fulfillment API

Data Partners who wish to support receiving orders from ECHO must provide an Order Fulfillment Service at their data center which interfaces directly with their Earth Science data system. ECHO will then transmit order submissions, quotations, and cancellations to the provider. The provider's Order Fulfillment Service fulfills the requested orders and communicates with the the ECHO API as the status of the order moves to completion. These status updates are used by the ECHO Operations team and the Data Partner's User Services group to provide user support to the science community.

The following links provide the necessary information to utilize the Order Fulfillment capabilities of the ECHO system. Also provided is a sample implementation of an Order Fulfillment Service which can be run by a Data Partner to receive orders from ECHO.

  • Order Fulfillment API Documentation - (HTML)
  • Order Fulfillment Types XML Schema - (XSD)
  • Order Fulfillment Service WSDL - (WSDL)
  • Sample Order Fulfillment Service - (ZIP)

Special Considerations

The following items outline some common areas which Data Partners should be aware of while fulfilling orders in ECHO..

SSL Secure Connections

Data Partners are encouraged to configure their Order Fulfillment Service endpoint to utilize the SSL protocol. In order to request ECHO to use the SSL protocol, a Data Partner can use PUMP to update their order policies with the public portion of the SSL certificate. The ECHO Operations team will review the certificate and activate the policy. The policy will be immediately in affect.

Provider Tracking ID

The Order Fulfillment API allows Data Partners to update the order status in ECHO with a field called 'provider tracking ID.' This field is the unique tracking ID which is assigned within the Data Partner's ordering service. In order to facilitate order tracking from ECHO, Data Partners should update the corresponding order in ECHO with their unique ID as soon as it is assigned.

Update Mechanism

A Data Partner can acknowledge an order submission with the following two update mechanisms:

  • Automatic - Indicates that the order has been completed by the provider and ECHO should consider the order closed.
  • Manual - Indicates that the provider will notify ECHO as the order is fulfilled.

ISO-3166 Country Names

The ECHO system allows user to enter a freeform string to define their contact, shipping, or billing address. In cooperation with the EOSDIS User Services Working Group, ECHO has created a list of approved country names that complies with the ISO 3166 standard. This list of names will appear in the ECHO supported PUMP and WIST tools for for user registration and order creation in WIST. ECHO will support all countries on this list and additional user-entered countries. ECHO Data Partners are encouraged to use this list in their applications to provide a consistent list of countries to all ECHO users. The full list can be downloaded below.

  • Providing customer support services in cooperation with the ECHO Operations team to resolve user community problems.

Reference Materials

The following links and documentation provide quick access to the most commonly used reference materials by ECHO Data Partners.

Page Last Updated: May 2, 2019 at 10:33 AM EDT