The Network Linked Data Index Geoprocessing with OGC API Processes

Update on the Network Linked Data Index processing capabilities using OGC API Process

The Network Linked Data Index (NLDI) is a search engine that indexes data to the flowpaths and/or catchments of a river network and provides discovery services based on position in that network. Like a search engine, it can cache and index new data. It also offers some convenient data services like basin boundaries and accumulated catchment characteristics.

Previous waterdata blog post (intro , new functionality and linked-data ) describe what the Network Linked Data Index (NLDI) is and what it can do in detail.

This post announces new capabilities that extend the base NLDI API with processing capabilities implemented as open-source python-based geoprocessing services that are exposed using the new OGC-API Processes specification.

NLDI API Background:

For those not familiar, a quick overview follows. The NLDI API offers an intuitive set of web resources via a linked-data endpoint. It is hosted on https://labs.waterdata.usgs.gov. ... below is used as shorthand for this base URL. For full API details, see the Swagger API documentation here.

A set of featureSources can be discovered at the linked-data root.
.../api/nldi/linked-data/

Each featureSource is made up of a set of features. each with its own featureID. A specific featureID can be accessed with a URL like:
.../api/nldi/linked-data/{featureSource}/{featureID}

The NLDI has a navigation api based on each featureID providing upstream/downstream search and access to network-data.
.../api/nldi/linked-data/{featureSource}/{featureID}/navigation
.../api/nldi/linked-data/{featureSource}/{featureID}/navigation/{mode}/{dataSource}

Two other capabilities stem from each featureID – one to retrieve a basin polygon upstream of the feature and one to retrieve local, total accumulated, or divergence-routed accumulated landscape characteristics.
.../api/nldi/linked-data/{featureSource}/{featureID}/basin
.../api/nldi/linked-data/{featureSource}/{featureID}/{local|tot|div}

comid is a “special” featureSource which corresponds to identifiers for the catchment polygons and flowpath lines of the base index.
.../api/nldi/linked-data/comid/

The comid feautureSource offers a position endpoint allowing discovery of network identifiers for a given lon/lat location. This is a simple “point in polygon” query that returns the flowline for the catchment area the provided coordinates are in.
.../api/nldi/linked-data/comid/position?coords=POINT({lon} {lat})

There is also a hydrolocation endpoint that returns a linear reference to a flowline. If the provided point is within 200 meters, it is “snapped” to the flowline, otherwise the linear reference is derived using a “raindrop trace” that follows an elevation surface downstream to the nearest flowline.
.../api/nldi/linked-data/hydrolocation?coords=POINT({lon lat})

NLDI Processing Updates:

The NLDI hydrolocation and basin endpoints both rely on some custom elevation-based processing. The two processes are referred to as “raindrop trace” and “split catchment” algorithms. Two other algorithms, both to retrieve cross sections are included in the current (Spring 2022) NLDI processing services. These algorithms retrieve cross sections either at a point along a flowline from the NLDI or between two provided points (presumable spanning a river to form a cross section).

These raindrop trace an split catchment algorithms are available as stand alone python packages: nldi-xstool and nldi-flowtools as well as hosted processing services via the NLDI “pygeoapi” server. pygeoapi is a python OGC API server that the USGS waterdata teams use for a number of applications.

Both the hydrolocation and basin endpoints use the raindrop trace algorithm. It ensures that a flowline within the local catchment of a selected point is found, rather than one that is nearby but in a different catchment and the point used for basin retrieval is along a flowline rather than a small dributary implied by elevation data.

The second process called in the code behind the basin endpoint is the split catchment algorithm. This algorithm requires that a precise location along a flowline be provided (as can be derived from the raindrop trace algorithm). Given this point, the process retrieves needed data to delineate a “split catchment”, returning one polygon upstream of the provided point and one downstream. These two polygons “split” the catchment polygon that defines the area that drains to the flowline in question. This split catchment can be used in conjunction with an upstream basin to provide a “precise” basin that is delineated to any provided location.