Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

SWOT Data Versioning

SWOT data periodically undergoes reprocessing, where data products are recreated from the original observations with updated processing algorithms. This results in a new data collection version.

Hydrocron supports multiple versions of SWOT data collections. As of version 1.8.0, Version D is the default — omitting the optional collection_name parameter will return Version D data. To retrieve data from a specific collection version, use the collection_name: string, required: no request parameter.

SWOT collection names supported by Hydrocron include:

Version D (default):

Version 2.0:

SWORD Version and Feature ID Compatibility

Reach and node IDs are defined by the SWOT River Database (SWORD). Version 2.0 uses SWORD v16, while Version D uses SWORD v17b. A small number of reach and node IDs differ between the two versions as a result. Users comparing data across collection versions should be aware that the same feature ID may not refer to the same geographic feature.

See SWORD Version Differences for details.

Parent Collections and Sub Collections

SWOT hydrology data products are organized into parent and child collections. The parent collections indicate the general feature type (river or lake):

and the sub collections indicate the specific feature or subtype of data (reach or node for rivers, prior, observed, or unassigned for lakes)

The SWOT Product Description Documents for SWOT Rivers and Lakes contain more information about the differences between subtypes of data. Note that currently Hydrocron does not support the lake subtypes of ‘observed’ and ‘unassigned’.

Collection name and feature type

Specifying sub collections in requests to Hydrocron is not necessary to distinguish the type of data to return, as you also specify whether you are looking for Reach, Node, or PriorLake data with the feature : string, required: yes parameter.

Note that if you mix feature types in the feature : string, required: yes and collection_name: string, required: no parameters, the collection_name: string, required: no parameter takes precedence. If you request feature_id : string, required: yes for a feature type that is different that what you request in collection_name: string, required: no, you will get an error.

For example, here we request feature=Reach with feature_id=78340600051 (a reach feature), but collection_name=SWOT_L2_HR_LakeSP_2.0. In this case you will get an error because Hydrocron will try to query the Lakes table for the given reach_id.

https://soto.podaac.earthdatacloud.nasa.gov/hydrocron/v1/timeseries?feature=Reach&feature_id=78340600051&output=geojson&start_time=2024-01-25T00:00:00Z&end_time=2024-03-29T00:00:00Z&collection_name=SWOT_L2_HR_LakeSP_2.0&fields=reach_id,time_str,wse,slope

CRID

The CRID indicates the version of the processing software that was used to generate the data. When data is first delivered to PO.DAAC and ingested into the archive, the CRID will be the forward-streaming version. If that data is later reprocessed, the CRID will be updated to indicate the reprocessing version. Hydrocron only keeps one version of a given observation at a time. If the data has been reprocessed, it will overwrite the earlier forward-streaming version with the reprocessed version.

Note that you cannot query by CRID, but you can return it as a field in the request and see which CRID was used to process the data that is being returned.