The approach to the below products is to provide documentation on
how to produce the below products from the xenia table schema and allow the developers and web designers to
assemble (mix and match) these products into their website as they best see fit. Here are a few notes on my basic
development plan
Xenia Sample Case
Graphs
Time series graphs
Graphs dynamically created on user request or system pregenerated for differing hourly/daily/weekly/monthly/yearly time spans and observations.
see
http://nautilus.baruch.sc.edu/twiki_dmcc/bin/view/Main/CarolinasCoastLite#archival_time_series
Profile/vector plot graphs
Documentation coming...
Regularly generated file outputs
System pregenerated files available via HTTP for differing hourly/daily/weekly/monthly/yearly time spans and observations.
- CSV files produced by month broken out by both observation type(all platforms for a specific observation type) and platform(all observation types for a specific platform)
- KML for Google Earth placemarks and overlays similar to those documented at ObsKML
- XML/RSS/WFS (or perhaps GeoRSS http://georss.org) feeds for latest platform readings similar to ObsKML
- Shapefile outputs representing regional maps by observation type
User query
Hoping to limit query to smaller requests for not more than a month time span. Larger data request needs can hopefully be satisfied by downloading the regularly produced CSV or other files.
Query tool should look similar to existing at
http://nautilus.baruch.sc.edu/carocoops_website/buoy_query.php?platform_id=WLS2&observation_id=all
or DODS/OPeNDAP 'Data by Observatin Type' request at
http://trident.baruch.sc.edu/dods/index.html
Quality Control and Notification
The 'extra' schema table elements are designed to allow for test parameters and sub-tests to be performed and quality control flags applied to the data. Quality tests or other user-defined tests may also trigger an action resulting in email(or possibly other) notification.
Web services
Critical documents
The critical components for community interoperability in my opinion are:
Optimally at the larger community level the fewer or more similar these types of references the better, but we may still end up with several 'standards' to choose from and map between. Hoping also that we can start simple with HTTP/XML oriented(
REST oriented) request/response approach and adopt more complex data transport protocols like SOAP as needed.
Latest approach
Earlier experimental web services
These represent some of the earlier web service methods being used which may still be in consideration because of their structure/simplicity.
getLatest(parameter_list, platform_id_list, lat/lon/z bbox) => xml response
getTimeRange(parameter_list, platform_id_list, lat/lon/z bbox, time_range) => xml response
An example of the type of xml output currently under consideration is shown at
http://marinemetadata.org/examples/mmihostedwork/demos/accessthrumetadata/instancesystem.xml
more notes at
http://marinemetadata.org/userexp/simplesensorml/?searchterm=sensorml http://twiki.sura.org/twiki/bin/view/Main/SoapliteSeacoos
Providing an OGC SOS(Sensor Observing System) compliant web service documented at
http://www.oostethys.org/sos-cgi-cookbook-v0.1
http://nautilus.baruch.sc.edu/twiki_dmcc/bin/view/Main/OOSTechKML
to top