NWIS, STORET, and XML

1
NWIS, STORET, and XML

• National Water Quality Monitoring Council
• August 20, 2003

2
Purpose

• Describe progress in providing an integrated view
  of NWIS and STORET data
• Show preliminary ideas for turning ACWI Water
  Quality Data Elements into a practical XML Schema
  for describing sampling stations

3
NWIS and STORET

• USGS and EPA signed an agreement on Management of
  Water Quality Data on January 13, 2003. Key
  elements include
• Geospatial internet-based query tool
• Joint team of technical staff to outline options
  and identify tasks
• References ACWI Data Elements

4
Geospatial query tool
Local STORET
NWIS
NWISWeb
Transactional
Query Tool
Distribution
5
Phases of development become more challenging
Phase Common data in portal Mapping interface How users get full data sets for stations
1 Station name/number lat/lon One-time prototype transfer of locations to geospatial query tool Table of links to STORET and NWISWeb
2 Location (watershed, state, county) agency general site type (surface-water, well, lake, etc.) Regular updates provided to geospatial query tool Station-by-station links to STORET and NWISWeb
3 Summary info. on constituent groups and sampling frequency " "
4 Links to all data, allowing detailed selections Standards-based web mapping services support many interfaces Portal acts as intermediary to deliver data in single format
5 " Standards-based web feature services allow interfaces to manipulate data display Delivered in a standard XML schema for water-quality data
6
Why do we need an XML Schema?

• Any advanced Water Portal concept (index,
  warehouse, distributed database, web service,
  etc.) works a lot better with a standard way to
  transfer data
• Designing an XML schema enforces a discipline on
  the data model
• ACWI Data Elements is a good start
• The devil is in the details!

7
A (very) DRAFT XML schema for water-quality data
station description
8
Cautions!!!

• We need to determine the scope of the data
  elements. Which ones actually will be needed in a
  data repository?
• Elements must be matched to missions and goals.
  Most data systems probably will use a subset of
  the schema.
• Need critical review by experts in XML Schema.

9
Some design principles

• Strictly define critical elements on which we
  commonly perform searches, such as
• lat/lon
• station identification and
• standard station type.
• Allow more flexibility on documentation elements
  (e.g. method of altitude determination).
• Allow documentation by citation
• Individual databases can redefine by restriction.

10
Standards and Recommendations

• ACWI Data Elements
• (Draft) Federal XML Developers Guide
• XML Schema style
• EPA Environmental Data Registry
• Data element names
• OpenGIS Geography Markup Language
• Describe geographic features
• ISO 8601
• Date, time
• HR-XML Consortium
• Names and addresses

They dont all agree!
11
Name and address elements are defined by HR-XML
Consortium
No need to invent our own!
12
Authority A Reference

• Defines code sets, names, methods, or
  explanations
• Allows great flexibility in documentation

13
Station where you sample
Simple, standard types (5-6?) plus user-defined
types
14
Station Location
Link to GML for subfeatures
15
Extension of Schema

• Tie results of sampling to station or
  sub-features of a station
• 6.0 Sample Collection
• 7.0 Sample Analysis
• Field trip information?
• Where does 3.0 Reason for Sampling fit?
• Why did we select this station?
• Why did we collect this sample?

16
Next Steps for XML Schema

• Refine schema with expert help
• Determine role of schema in a water portal
• Scope of data elements which are needed and
  which can we defer?
• Redefine schema by restriction to match business
  requirements
• Test with data output from NWIS and STORET