1 / 25

WG Points of Contact: Terence Van Zyl, MERAKA Institute Hervé Caumont, OGC IP Team / ERDAS

GEO Architecture and Data Committee Task AR-07-02 Architecture Implementation Pilot Products, Sensors, Models Access Services WG. WG Points of Contact: Terence Van Zyl, MERAKA Institute Hervé Caumont, OGC IP Team / ERDAS December 3rd, 2008. Access WG Charter.

rona
Download Presentation

WG Points of Contact: Terence Van Zyl, MERAKA Institute Hervé Caumont, OGC IP Team / ERDAS

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. GEO Architecture and Data CommitteeTask AR-07-02 Architecture Implementation PilotProducts, Sensors, Models Access Services WG WG Points of Contact: Terence Van Zyl, MERAKA Institute Hervé Caumont, OGC IP Team / ERDAS December 3rd, 2008

  2. Access WG Charter • The Access WG provides coordination and guidance to achieve interoperable Access Services to products, sensors and models. • This relies on the AIP-2 participant's offerings (their proposed contributions to the pilot). • By doing so, the Access WG contributes with other WG to enable a Global EO System of Systems, through scenarios and use cases definition.

  3. AIP-2 Participants with a focus on Access Services

  4. Data Product Access • 23 Primary responses: CIESIN, CNES, EPA, ESA, GEO-Ukraine, ICAN, ICT4EO, IP3, ISPRA, JAXA, Mines Paris Tech, NASA World Wind, NOAA IOOS, NOAA NCDC GOSIC, NOAA NCDC NEXRAD, NOAA NCDC NIDIS, NOAA NCDC NOMADS, NOAA/NASA GOES-R and GMU CSISS, Northrop Grumman, SURA/NIMSAT/GoMOOS, Spot Image, USGS, Washington Univ St. Louis • 15 Contributing responses: ACRF, Caribbean Flood Team, ERDAS, ESIP AQ Cluster, ESRI, ESRI Canada, NOAA SNAAP

  5. Data Product Access Topics • Services: WMS, WCS and WFS • Encodings Formats : NetCDF/CF, KML, GML, JPEG2000, PNGs, GeoTIFF, MrSID, Geolocated JPEGs, CADRG, CIB, Shapefile • EO Data: Radar, Optical, Weather, Precipitation, TRMM flash flood potential • ALOS Imagery: Panchromatic, Near IR, SAR • High-frequency radar • in situ oceanographic data • Coastal Web Atlas holdings • Multistandard platform (MapServer, ArcIms Server, SDE, etc) • SPIDR web services • IP3 ENM Species Distribution Analysis service • SoDa W*S is already a Special Argmt • Broker Service to access OGC Web services, THREDDS/OpenDAP, GBIF

  6. Sensors and Models Access • 7 Primary responses: GEO-Ukraine, ICT4EO, IP3, NOAA IOOS, Northrop Grumman, Spot Image, SURA/NIMSAT/GoMOOS • 5 Contributing responses: Caribbean Flood Team, Compusult, NASA World Wind, NOAA NCDC NEXRAD, Noblis

  7. Sensors and Models Access Topics • Sensor Web Enablement: SOS, SPS, SAS, SensorML, O&M • EO-1, TRMM, Envisat, SRTM, MODIS, RADAR, RT weather, fire • Weather, fire, flood areas and index • Flood model outputs • Bluesky Smoke model • Model Web • CALPUFF and WRF model outputs

  8. Goal, audience, and usage of the 'Use cases' • Use Cases are provided to model the interactions of a (sub)system under study with its environment (actors, being some kind of user interface or other systems) • Co-authored by systems analysts and end users • A starting point for tests design • Use Cases are developed by the AIPTransverse Technology WG • Scenarios are developed by the AIP Community WG • Both support AI Pilot storyboards, to test & demonstrateinteroperability amongst online persistent systems and services • Running a scenario over several systems • Activating systems functions as described in the use cases

  9. Basic set of use cases / capture persistent access • Accessing a product • Accessing a model • Accessing a sensor for observations • Accessing a rendered output from a product or model • Ordering a product • Invoking the disaster charter for access to products • Subscribing to a sensor alert • Commanding a sensor

  10. Accessing a Product • Description: • Access to various web resident services including WFS, WCS, OpenDAP; encodings; CRSs • Lead: • Hervé Caumont • Status: • Started • was agreed during WG Telecon • will be posted on WG Website (this week)

  11. Accessing a Model • Description: • Access to a web resident services that fronts a model • Lead • Glenn Rutledge • Status • Started

  12. Accessing rendered output from a product or model • Description: • Access to a map portrayal service for products or models visualization • Lead: • No lead • Status • Not started

  13. Accessing a Sensor for Observations • Description: • Access to a web resident sensor fronted by a web service supporting OGC-SOS • Lead • Luis Bermudez • Status • Started

  14. Subscribing to a Sensor Alert • Description: • Access to a web resident sensor fronted by a web service supporting OGC-SAS for the purpose of receiving alerts • Lead: • No Lead • Status: • Not started

  15. Commanding a Sensor • Description: • Access to a web resident sensor fronted by a web service supporting OGC-SPS for the purpose influencing future observations • Lead • Terence van Zyl • Status • Started

  16. Ordering a Product • Description: • Access a product through the tasking of a specific sensor/platform • Lead • No Lead • Status • Proposed as additional use case

  17. Invoking the Disaster Charter • Description: • Use case to describe how in the case of a disaster to speed up the process of access to the charter • Lead • No lead • Status • Proposed as additional use case

  18. Template for writing Access Use Cases

  19. How to populate the initial Use Cases • When writing, keep focus on the subsystem under study (the Web Coverage Service, the Sensor Alert subscription service…) • Give awaited inputs and provided outputs • Document for modularity • Use verbs / action (‘server’ receives request for a single band geoTIFF…, ‘server’ sends…) • Consider the cumulated / consolidated Use Cases view, and document the right modularity and uniqueness of each Use Case

  20. Simple example

  21. Status • General WG Tasks being completed • Arrive at a set of generic principles that underpin all persistent access • Provide through a Google form a way for outsiders to capture experience, issues, etc… relating to use cases • Arrive at a set of measures that will describe our success and the effectiveness of use cases • Do a self evaluation • Cycle through and refine Use Cases definitions

  22. Invitation to Contribute • The Process Being Followed per Use Case • Identify a use case that captures persistent access • Invite people to contribute and comment on use cases • Refine/Populate the use cases to support interoperability testing of components and services within the AI Pilot • Capture comments • Continue cycling through this process refining each iteration

  23. Invitation to contribute

  24. Contact Information • Getting to the Access WG Web page: • http://sites.google.com/site/geosspilot2 • Menu entry access-services-working-group • Subscribing to the Access WG Mailing List: • https://lists.opengeospatial.org/mailman/listinfo/aip_access • Access WG weekly telecons to discuss issues arising and new use cases that need to be addressed • Announcements through Access WG mailing list

  25. Thank you

More Related