html5-img
1 / 35

CUAHSI WaterML

CUAHSI WaterML. Ilya Zaslavsky (SDSC), David Valentine (SDSC), Tim Whiteaker (UT-Austin) /editors/ CUAHSI = Consortium of Universities for the Advancement of Hydrologic Sciences, Inc.;. Background.

zyta
Download Presentation

CUAHSI WaterML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CUAHSI WaterML Ilya Zaslavsky (SDSC), David Valentine (SDSC), Tim Whiteaker (UT-Austin) /editors/ CUAHSI = Consortium of Universities for the Advancement of Hydrologic Sciences, Inc.;

  2. Background • CUAHSI HIS: NSF-supported collaborative project: UT Austin + SDSC + Drexel + Duke + Utah State (www.cuahsi.org/his/). PI: David R. Maidment (UT-Austin) • A cyberinfrastructure project • Current focus: providing uniform access to heterogeneous observations data, from different agencies • Plus an easy way to publish hydrologic observations data • And to assemble comprehensive observations databases for your watershed, catchment, etc. • From ad hoc SOAP wrappers for agency data to a consistent schema, agency buy-in, and support for multiple clients => WaterML

  3. Hydrologic Information System Service Oriented Architecture Web portal Interface (HDAS) Information input, display, query and output services Preliminary data exploration and discovery. See what is available and perform exploratory analyses 3rd party servers Web services interface e.g. USGS, NCDC GIS Matlab Observatory servers Workgroup HIS IDL SDSC HIS servers Splus, R D2K, I2K Programming (Fortran, C, VB) Downloads Uploads HTML -XML Data access through web services WaterOneFlow Web Services WSDL - SOAP Data storage through web services

  4. The CUAHSI Community, HIS and WATERS Government: USGS, EPA, NCDC, USDA Industry: ESRI, Kisters, OpenMI CUAHSI HIS WATERS Network Information System HIS Team WATERS Testbed Domain Sciences: Unidata, NCAR LTER, GEON Super computer Centers: NCSA, TACC HIS Team: Texas, SDSC, Utah, Drexel, Duke CUAHSI: 116 Universities (Nov. 2006)

  5. CUAHSI HIS as a mediator across multiple agency and PI data • Keeps identifiers for sites, variables, etc. across observation networks • Manages and publishes controlled vocabularies (in the Annex to the WaterML paper), and provides vocabulary/ontology management and update tools • Provides common structural definitions for data interchange • Provides a sample protocol implementation • Governance framework: a consortium of universities, MOUs with federal agencies, collaboration with key commercial partners, led by renowned hydrologists, and NSF support for core development and test beds

  6. WaterML design principles • Driven largely by hydrologists; the goal is to capture semantics of hydrologic observations discovery and retrieval • Relies to a large extent on the information model as in ODM (Observations Data Model), and terms are aligned as much as possible • Several community reviews since 2005 • Driven by data served by USGS NWIS, EPA STORET, multiple individual PI-collected observations • Is no more than an exchange schema for CUAHSI web services • The least barrier for adoption by hydrologists • A fairly simple and rigid schema tuned to the current implementation • Conformance with OGC specs not in the initial scope

  7. USGS Data Source Return network information, and variable information within the network Streamflow gages Network Return site information, including a series catalog of variables measured at a site with their periods of record Neuse River near Clayton, NC Sites ObservationSeries Discharge, stage, start, end (Daily or instantaneous) Return time series of values Values 206 cfs, 13 August 2006 {Value, Time, Qualifier} Point Observations Information Model • A data source operates an observation network • A network is a set of observation sites • A site is a point location where one or more variables are measured • A variable is a property describing the flow or quality of water • An observation series is an array of observations at a given site, for a given variable, with start time and end time • A value is an observation of a variable at a particular time • A qualifier is a symbol that provides additional information about the value

  8. Data Source and Network Controlled Vocabulary Tables Sites Variables Values Metadata e.g. mg/kg, cfs e.g. depth Streamflow Depth of snow pack Landuse, Vegetation e.g. Non-detect,Estimated, Windspeed, Precipitation A data source operates an observation network A network is a set of observation sites A site is a point location where one or more variables are measured A variable is a property describing the flow or quality of water A value is an observation of a variable at a particular time Metadata provide information about the context of the observation. Observations Data Model Schema (version 4.0) From Ernest To, David Maidment, CRWR

  9. Challenges… (1/2) • Sites • STORET has stations, and measurement points, at various offsets… • Site metadata lacking and inconsistent (e.g. 2/3 no HUC info, 1/3 no state/county info); agency site files need to be upgraded to ODM… • A groundwater site is different than a stream gauge… • Censored values • Values have qualifiers, such as “less than”, “censored”, etc. – per value. Sometimes mixed data types.. • Units • There are multiple renditions of the same units, even within one repository • There may be several units for the same parameter code (STORET) • If no value recorded – there are no units?? • Unit multipliers • E.g. NCDC ASOS keeps measurements as integers, and provides a multiplier for each variable • Sources • STORET requires organization IDs (which collected data for STORET) in addition to site IDs • Time stamps: ISO 8601 • A service to determine UTC offsets given lat/lon and date??

  10. Challenges… (2/2) • Values retrieval • USGS: by site, variable, time range • EPA: by organization-site, variable, medium, units, time range • NCDC: fewer variables, period of record applies to site, not to seriesCatalog • Variable semantics • Variable names and measurement methods don’t match • E.g. NWIS parameter # 625 is labeled ‘ammonia + organic nitrogen‘, Kjeldahl method is used for determination but not mentioned in parameter description. In STORET this parameter is referred to as Kjeldahl Nitrogen. • One-to-one mapping not always possible • E.g. NWIS: ‘bed sediment’ and ‘suspended sediment’ medium types vs. STORET’s ‘sediment’. • Ontology tagging, semantic mediation • Contolled vocabularies are in Annex A

  11. NWIS Daily Values (discharge), NWIS Ground Water, NWIS Unit Values (real time), NWIS Instantaneous Irregular Data, EPA STORET, NCDC ASOS, DAYMET, MODIS, NAM12K, ODM • - From different database structures, data collection procedures, quality control, access mechanisms  to uniform signatures … Water Markup Language • - Tested in different environments • - Standards-based • - Can support advanced interfaces via harvested catalogs • - Accessible to community • - Templates for development of new services • Optimized, error handling, memory management, versioning, run from fast servers • Working with agencies on setting up services and updating site files

  12. Response Types SiteInfo Variables TimeSeries Key Elements site sourceInfo seriesCatalog variable timeSeries values queryInfo WaterML key elements GetSiteInfo GetVariableInfo GetValues

  13. variablesResponse variables 1 many timeSeriesResponse variable queryInfo timeSeries criteria sourceInfo queryURL variable values Structure of responses sitesResponse queryInfo site criteria siteInfo seriesCatalog 1 queryURL many series variable variableTimeInterval

  14. Elements Defining Spatial Location SourceInfoType for observation sites for continuous surfaces SiteInfoType DatasetInfoType (other site information) child elements (other dataset information) GeogLocationType GeogLocationType LatLonPointType LatLonPointType LatLonBoxType

  15. SiteInfoResponseType • Namespaces • queryInfo • site Network Sites Variables

  16. userparameters query URL queryInfo example • Parameters sent to service • URLs called (if external resource)

  17. siteInfo • Name • Site Code • Location

  18. geoLocation • geogLocation – geographic coordinates • LatLon point • LatLon box • localSiteXY – projected coordinates

  19. series • variable – what is measured • valueCount – how many measurements • variableTimeInterval – when is it measured TimePeriodType

  20. variable • variableCode – global identifier • variableName • units Sites Variables Values TimePeriodType

  21. Compare with… variableTimeInterval • TimePeriodType – date range (including “last n days” • TimeInstantType – single measurement

  22. queryInfo name code location site seriesCatalog what how many variables when SiteInfo response TimePeriodType

  23. VariablesResponseType • variable – same as in series element • Code, name, units Sites Variables Values

  24. TimeSeriesResponseType • queryInfo • timeSeries • sourceInfo – “where” • variable – “what” • values Sites Variables Values

  25. sourceInfo • SiteInfoType • Same as siteInfo element • code, name, location • DataSetInfoType • For data continuous in space • LatLonPointType • LatLonBoxType

  26. Compare with… values • Each time series value recorded in value element • Timestamp, plus metadata for the value, recorded in element’s attributes qualifier ISO Time value

  27. value metadata examples • qualifiers • censorCode (lt, gt, nc) • qualityControlLevel (Raw, QC’d, etc.) • methodID • offset • offsetValue • offsetUnitsAbbreviation • offsetDescription • offsetUnitsCode

  28. TimeSeries response queryInfo location variable values

  29. Clients • Tested with .Net and Java • Desktop clients: Excel, Matlab, ArcGIS, VB.NET,more beingwritten • Web client: DASH (Data Access System for Hydrology): http://river.sdsc.edu/DASH(beta)

  30. Direct DB connection Current Deployment Architecture VS 2005 DASH ODM GIS Data Mxd Service WaterOneFlow Web Services ODM tools ODM Loader AGS Server SQL Server ArcGIS 9.2 IIS Windows 2003 Server 4 GB Ram 1 TB Disk Quad Core CPU

  31. 6 5 4 2 3 1 WORKGROUP HIS SERVER ORGANIZATION STEPS FOR REGISTERING OBSERVATION DATA DASH Web Application Web Configuration file Stores information about registered networks MXD Stores information about layers Layer info,symbology, etc. WSDLs, web service URLs Connectionstrings Spatial store WOF services NWIS-IID points NWIS-IID WS USGS SQL Server NWIS-DV points NWIS-DV WS NWIS-IID NCDC ASOS points ASOS WS NWIS-DV STORET points STORET WS ASOS EPA TCEQ points TCEQ WS STORET BearRiver points BearRiver WS TCEQ TCEQ . . . . . . More WS fromODM-WS template More synced layers BearRiver My new points My new WS . . . More databases Background layers(can be in the same or separate spatial store) Geodatabase or collection of shapefilesor both Web services from a common template My new ODM ODMs and catalogs. All instances exposed as ODM (i.e. have standard ODM tables or views: Sites, Variables, SeriesCatalog, etc.) ODMDataLoader

  32. New network registration steps Using the ODM DataLoader, load your data into a blank ODM instance (this will create all ODM tables, including Sites, Variables and SeriesCatalog that HIS application relies on) Copy Web Services template to a new folder, edit the template web.config file to point to the new ODM, test to make sure the new service works as expected Create a point layer (a feature class in GDB, or a shapefile) from the new ODM’s Sites table or from GetSites web service (using GetSitesTool – this will also test the service) Add the point layer to the MXD document, specify symbology, scale-dependent rendering, etc. Add information about the new ODM, the associated web service, and the associated point layer, to HIS configuration file (see the first slide for the exact content) Restart the HIS service 1 2 3 4 5 6

  33. Near future • Need further reviewed, based on initial implementation • Within and beyond OGC membership • Further engage with hydrologic observation groups at agencies • Internationalization (with CSIRO WRON, European WISE, others?) • CUAHSI O&M profile? • Carry CUAHSI WaterML messages over O&M - need to talk with Simon about it… • Test it within an initiative (e.g. Oceans IE, or Water Data Interoperability Testbed, OWS-5? ) • Have a list of suggestions for versions after 1.0 (including linear referencing, GetCapabilities, WFS integration, handling multiple siteCodes and variableCodes in a single call) – more suggestions are welcome • Divorcing from implementation? Looking for golden middle in standard complexity…

  34. OGC Harmonization Best Practices • WaterML text includes steps for harmonizing with GML/O&M • Align spatial feature descriptions (e.g. using gml:Point, gml:Envelope) • Align service signatures (getCapabilities) • Align terminology with O&M • Provides guidance to other communities on harmonization steps

  35. Motion • EO/NRE WG recommends to the TC that the CUAHSI WaterML (document 07-041) be released as an OGC Discussion paper • Pending minor editorial changes • Proposed • Second: Ben Domenico • Unanimous • Roadmap: • Reporting initial implementation experience • CUAHSI WaterML 1.1, aligning with O&M • Testing within an OGC initiative

More Related