260 likes | 396 Views
Technical Deployment Task Team (TDTT) Recommendations. Steven Jackson FGDC Core Team Telecon 04 APR 2011. Agenda. Background Notional Technical Architecture Candidate Components Candidate Interfaces Contributing Data and Services Geospatial Platform V0 Next Steps. Bottom Line Up Front.
E N D
Technical Deployment Task Team (TDTT) Recommendations Steven Jackson FGDC Core Team Telecon 04 APR 2011
Agenda • Background • Notional Technical Architecture • Candidate Components • Candidate Interfaces • Contributing Data and Services • Geospatial Platform V0 • Next Steps
Bottom Line Up Front • The TDTT’s work is only the beginning • The team identified some potential next steps • The proposed notional architecture • Leverages existing capabilities heavily • Decentralizes data/services storage • Centralizes discovery • Will require funding to support centralized components • Open standards are key to implementation of the architecture
Background • Origin: • Assembled December 2010, as a functional team comprised of representatives nominated by FGDC partner agencies and the Geospatial Platform Core Team • Purpose: • Recommend a path forward for implementation of Geospatial Platform common services and shared infrastructure • Lead efforts to deploy "mature" capabilities identified in the Modernization Roadmap for the Geospatial Platform that provide a useful service, can be built upon, and can be undertaken quickly
Background • Approach: • Develop a set of requirements by evaluating existing Federal geospatial capabilities to determine their potential to meet the needs of the Geospatial Platform • Outcome: • Generate a Technical Deployment recommendation for the Geospatial Platform Core Team and FGDC Executive Committee which will include: • Notional technical architecture • Candidate solutions architecture(s)
Background • Dates • December 15, 2010 – Kick-Off Meeting • January 4 , 2011 – USGS’s Geospatial One Stop (GOS), Data.gov capability demos • January 5, 2011 – ESRI’s Geoportal Server (used by several federal organizations), Intelligence Community’s (IC) Enterprise Repository and Registry (ER2) capability demos • January 13, 2011 – NOAA’s EnvironmentalResponse Management Application® (ERMA), NASA’s Spatial Web Portal (SWP) capability demos • January 20, 2011 – Use Case development/review • February 4, 2011 – Initial Architecture produced • February 17, 2011 - USGS’s Global Earth Observation System of Systems (GEOSS) Clearinghouse, NASA’s Spatial Web Portal (SWP) capability demos • February 23, 2011 – Prototype Architecture produced • March 7, 2011 – Present Recommendations to Core Team
Background • Dates • March 8, 2011 – Present Recommendations to Coordination Group • March 9, 2011 – Present Recommendations to NGAC Intergovernmental Subcommittee • March 17, 2011 – Discuss Recommendations at NGAC • March 28, 2011 – Technical integration meeting • April 4, 2011 – Present Recommendations to Core Team
Background • Team Members: • Chair: Steven Jackson, NGA - Steven.P.Jackson@nga.mil • Myra Bambacus, NASA - myra.j.bambacus@nasa.gov • Jeff Booth, DHS - Jeffrey.Booth@dhs.gov • Paul Fukuhara, USDA - paul.fukuhara@ftw.usda.gov • Travis Hardy, DHS - Travis.Hardy@associates.dhs.gov • Doug Nebert, FGDC - ddnebert@usgs.gov • Kari Sheets, NOAA - Kari.Sheets@noaa.gov • Michelle Torreano, EPA - Torreano.Michelle@epamail.epa.gov
Notional Technical Architecture – Use Case • Casual User • This use-case describes the process of a casual user discovering and accessing data from multiple sources and displaying them together in a map for visual or print usage.
Notional Technical Architecture – Use Case • Advanced User • This use-case describes the process of an advanced user discovering and accessing data from multiple sources and applying them in a personal computing environment.
Notional Technical Architecture – Use Case • Publisher • This use-case describes the process of a publisher registering a data, service, or application resource into a platform catalog. A-16 Portfolio Designation is also handled within this use case.
Notional Technical Architecture – Use Case • Geospatial Viewer • This use-case describes the basic functionality to be included within the Geospatial Viewer with a focus on the base map content.
Notional Technical Architecture Data.gov Catalog Dublin Core Metadata View GeoPlatform Web Presence Phase I Phase II sends links Geospatial DSS Workbench Geospatial Query UI Geospatial Viewer Synchronized queries extends results with links Geospatial Catalog uses Web Metadata Editor FGDC/ISO Metadata View metadata as XML Geoprocessing Services asset display and query links to assets Geocoder Service Distributed search accesses metadata as XML harvest metadata FGDC/ISO metadata as XML plus data dictionary RDF Geo-Enabler Tool Geospatial Assets metadata Data, Services, and Apps Agency Geospatial Investment Information Federal (blue) and non-federal (green) geospatial metadata catalogs Planned Geospatial Data Activities
Contributing Data and Services • The Notional Technical Architecture is component-based • Open standards based components can be changed • Offers partners an opportunity to interact with the Geospatial Platform at several levels • The Geospatial Platform is an environment where Partners are able to share their content and gain access to the work of others while reducing their own operating costs
Contributing Data and Services • Publishers expose content (“the give”) in the Geospatial Catalog using the Web Metadata Editor • Focus is on public data/services. Each data/service maintains host user credentialing • Content is discovered through the Geospatial Query UI • Mappable data is passed to the Geospatial Viewer while other content is provided to the user for download • Publishers can register their catalog to support content search/harvest
Contributing Data and Services • Partners discover and use content (“the get”) within the Geospatial Platform or other within their own capabilities • Partners contribute their specific content to the Geospatial Platform and at the same time seek the specific content of others • Integrate data/services into their own environment to enhance their own mission • Minimize duplication
Contributing Data and Services GeoPlatform Web Presence Phase I Phase II Geospatial Query UI Geospatial Viewer Geospatial DSS Workbench Geospatial Catalog Web Metadata Editor Geoprocessing Services Geocoder Service Geo-Enabler Tool Geospatial Assets metadata Data, Services, and Apps Agency Geospatial Investment Information Federal (blue) and non-federal (green) geospatial metadata catalogs Planned Geospatial Data Activities
Geospatial Platform V0 • Deliverable of the TDTT was to stand up an initial instantiation of the Geospatial Platform • Team members examined “mature” capabilities for suitability • Version 0 developed to demonstrate Architecture • Intentionally integrated components of several organizations • Intended to facilitate detailed feedback and discussion
Geospatial Platform V0 GeoPlatform Web Presence Phase I Phase II OpenLayers Spatial Web Portal Geospatial Query UI Geospatial Viewer Geospatial DSS Workbench GEOSS Clearinghouse (GeoNetwork) Geospatial Catalog MERMAid GeoNetwork MERMAid Web Metadata Editor Geoprocessing Services Geocoder Service Geo-Enabler Tool Geospatial Assets metadata Data, Services, and Apps Agency Geospatial Investment Information Federal (blue) and non-federal (green) geospatial metadata catalogs Planned Geospatial Data Activities
Next Steps • Identify what Metadata Catalog attributes or triggers can be used to identify a base map record for the Geospatial Viewer. Work with the Geospatial Viewer to expose the base maps. • Identify what Metadata Catalog attributes would be required to facilitate A-16 Portfolio Management. Add those attributes to the Metadata Catalog. Additionally, need to document the reporting mechanism functionality through a Use Case.
Next Steps • Integrate the Status Checker into the catalog so that it can populate an attribute which will allow users to quantify the reliability of the service which they are looking to use. • The initial data content for the Geospatial Catalog must be identified and then integrated into the Catalog.
Next Steps • Need to investigate how the National Map can be used by the Geospatial Platform. Can the National Map be a destination for services found within the Geospatial Query UI? Can it be the/a Geospatial Viewer? • Need to investigate implementation of Phase II of the Geospatial Platform Web Presence. The FCC’s Broadband Map would serve as good test candidates because they are completed and standards-based.
Next Steps • The current architecture enables each organization to maintain their own user access and logging. Investigate the degree to which single sign-on is feasible or desired within the community. Publicly available data need not be access controlled.
Next Steps • Integrate the Status Checker into the Geospatial Catalog so that the long-term reliabilities of the services can be captured and used as a query property.
Summary • TDTT’s work should be used • As base material for subsequent Task Teams • Reference next steps • To communicate the desired end-state to partners and developers of the Geospatial Platform • Use Cases • Notional Architecture • As the foundation for the Geospatial Platform
Questions? • Thank you!