Unifying Standards for Water Data Exchange

Leveraging OGC API - EDR and pygeoapi

Benjamin Webb

Software Developer

Internet of Water

18+

 Employees across the

United States

2X

 Pace of growth over the last year, expected to continue

20+

Public and private collaborations to date

Helping organizations on the frontlines of our most

complex land, water, and social challenges leverage 

data and technology to accelerate impact. ​

2020

Founded by the Lincoln Institute of Land Policy

CGS is the technical engine for the Internet of Water Coalition providing digital infrastructure and implementation support to help stakeholders across the water data ecosystem modernize water data publication and management.

​

Ongoing work in OGC Working Groups

• Hydro-Domain WG
• TimeSeriesML SWG
• Observations, Measurements, and Samples SWG

The Water Data Challenge: Why Standards Matter

Credit: Daniele Levis Pelusi via Unsplash

• Water data comes from diverse sources but lacks standardization.
• Disparities in formats hinder analysis, sharing, and decision-making.
• Unified standards like WaterML 2.0 and OGC API - Environmental Data Retrieval (EDR) hope to address these challenges.
• “Interoperability is a big word.”

Water Data Diversity

• Geospatial Features: Representing physical entities like rivers and lakes.
• Time Series: Long-term monitoring of parameters like flow and quality.
• Raster Data: Satellite and remote sensing imagery for broad insights.

Finding Balance in Compatibility and Complexity

• WaterML2.0 is a standard information model for the representation of water observations data

​

• XML is the serialization format of choice

​

• Accepted in 2012 as an OGC Standard

https://gin.gw-info.net/GinService/sos/gw?REQUEST=GetObservation&VERSION=2.0.0&SERVICE=SOS&offering=GW_LEVEL&featureOfInterest=ab.mon.667&observedProperty=urn:ogc:def:phenomenon:OGC:1.0.30:groundwaterlevel

Harmonizing OGC Standards: WaterML2.0, O&M, and TSML

WaterML2.0

Observations and Measurements

Based on

Time Series Markup Language

Derived from

Use Case 1: Web App Development for Community Engagement and Education

User Profile:

​

• Audience: Community members, educators, local policymakers.

​

• Needs: Easy-to-use, interactive water data for education and decision-making.

​

• Goals: Understand local water resources, advocate for policy, educate others.

​

• Challenges: Limited technical knowledge, need for web-friendly design.

​

Use Case 1: Web App Development for Community Engagement and Education

• Design implications for WaterML2.0
• Utilize OGC API - EDR (Environmental Data Retrieval) for streamlined access to spatial and temporal data, enabling direct integration into web maps.

​

• And leverage JSON for compact, browser-friendly data serialization, optimizing performance in web environments.

​

• And define a best practice to expose it

Use Case 2: Scientific Analysis for Water Resource Management

User Profile:

​

• Audience: Researchers, water resource managers, environmental scientists.

​

• Needs: Access to detailed, accurate water data for analysis and modeling.

​

• Goals: Analyze water quality, monitor trends, inform policy and conservation strategies.

​

• Challenges: Handling complex datasets, need for detailed metadata.

Use Case 2: Scientific Analysis for Water Resource Management

• Design Implications for WaterML2.0
• To be updated to include the revision of O&M (ISO 19156:2011) => Observations, Measurements and Samples a.k.a ‘OMS’ (ISO 19156:2023)

​

• And TimeSeries ML (issued from Part 1) : also currently integrating OMS

​

• And define a best practice to expose it

Harmonizing OGC Standards: WaterML2.0, OMS, and TSML 2

WaterML2.0

Observations, Measurements, and Samples

Update to align with

Time Series Markup Language 2

Update to align with

One Representation to Rule them All

• Candidate Serializations:
• CoverageJSON
• OGC SensorThings API
• CSV
• …�

?

Is SensorThingsAPI really a serialization?

…no

but it does expose all the Time-Value Pair metadata required for TSML/OMS

Is SensorThingsAPI really interoperable?

…no

but it does expose a consistent logical model for Sensor and Observation data

SensorThingsAPI as OGC API - EDR

https://sta-edr.internetofwater.dev/

EDR as webmap ready time series

EDR as webmap ready coverage

OAFeat for Hydrologic Features

OAFeat for Gages along a Hydrologic Feature

https://reference.geoconnex.us/collections/gages/items?mainstem_uri=https://geoconnex.us/ref/mainstems/29559

How well are we doing?

Needs: Easy-to-use, interactive water data for education and decision-making.

Needs: Access to detailed, accurate water data for analysis and modeling.

Recommendations

• Develop modular standards that allow users to select only the components they need, reducing complexity for specific use cases.
• Build tools and APIs that bridge different standards, enabling seamless data exchange across platforms.
• Strengthen partnerships between technical experts, data providers, and user communities to guide development and adoption.

​

Further Reading

• WaterML 2.0: https://www.ogc.org/publications/standard/waterml/
• OGC API - EDR: https://ogcapi.ogc.org/edr/
• STA-EDR pygeoapi provider: https://github.com/cgs-earth/pygeoapi-plugins
• Example EDR query: �https://sta-edr.internetofwater.dev/collections/USGS/cube?f=html&bbox=-105.353823,32.425507,-103.617983,34.106848

​

Questions?

Please reach out!

Benjamin Webb

bwebb@lincolninst.edu

https://github.com/webb-ben

​

113 BRATTLE STREET CAMBRIDGE MA 02138 LINCOLNINST.EDU @LANDPOLICY

25