Geospatial XSL Transformations and Web Services for

Document Sample
scope of work template
							07/MAV/SE/01



     Geospatial XSL Transformations and Web Services for
                 National Marine Boundaries
                     FY 2007 Proposal to the NOAA HPCC Program

                                        November 1, 2006

                          | Title Page | Proposed Project | Budget Page |

Principal Investigator:   David Stein

Line Organization:        National Ocean Service – Coastal Services Center
Routing Code:             N/CSC
Address:
                          Coastal Services Center
                          2234 South Hobson Ave
                          Charleston, SC 29405-2413


Phone:                    (843) 740-1310
Fax:                      (843) 740-1224
E-mail Address:           dave.stein@noaa.gov



Tony LaVoi                   Daniel Martin                  Ed Dempsey
tony.lavoi@noaa.gov          daniel.martin@noaa.gov         ed.demsey@noaa.gov



Proposal Theme:           Technologies for Modeling, Analysis, or Visualization




                                Signature on file                 Signature 3      (optional)
David Stein                     Tony LaVoi                        Authorizing Official 2
Program Analyst                 Branch Chief                      Title
Coastal Services Center         Coastal Services Center           Organization
     Geospatial XSL Transformations and Web Services for
                 National Marine Boundaries
                          Proposal for FY 2007 HPCC Funding

                            Prepared by: David Stein/Daniel Martin

Executive Summary:

NOAA line offices actively support and rely upon Internet-based map services as a mechanism
to bridge the scientific and management communities to their broad constituency. Frequently
these map services are dependent on a single data warehouse and are presented as graphics on a
web page from a single application server. This implementation model does not take advantage
of the sophisticated web-services functionality that is now available to the NOAA community
and which can better serve the basic data sharing, integration and visualization needs.

A more complete utilization of the web service stack would include SOAP, WSDL, UDDI, the
Geography Markup Language (GML) and Web Feature Services (WFS). This offers benefits
such as service discovery, multipoint data sources, easier integration with non-geospatial web
services, more sophisticated visualization, and sophisticated client-side processing. Some of the
barriers to a more full utilization of web map services are now being realized through new
products, Open Geospatial Consortium (OGC) and W3C standards, and a growth and acceptance
of web service enabled clients. To complete the web map service delivery cycle translators are
still needed between the providers of services, using OGC and other REST or SOAP services
such as ESRI, and the geospatial clients that support open and alternate standards.

The NOAA Coastal Services Center, specifically the Ocean Governance Team and the Data
Transport Laboratory, proposes to serve multi-agency national marine boundaries to the public
using feature web map services and standards-based application schemas (see Figure 1).
EXtensible Stylesheet Language Transformations (XSLT) will be written to bridge data sources
in GML, ESRI/AXL and ESRI/SOAP output to three sample clients that produce text/HTML,
the GoogleMaps KML and Macromedia Flash.

Figure 1
Problem Statement:
“Basic access to large volumes of relevant NOAA geospatial data is limited by the
underutilization of web map service technology because of a lack of translators to open and
alternative clients.”

       Feature based web map server capabilities exists in NOAA, however they have been
       based on a commercial XML schema (AXL) that has not been adopted beyond the
       ArcGIS product suite. As a result:
          o map servers primarily render graphics only
          o feature based data is rarely or only awkwardly delivered to a client, and
          o non-geospatial clients must rely on feature-based data from a static local file.

Meeting the HPCC Theme Topic: Technologies for Modeling, Analysis, or Visualization

Enabling Applications

Integration and re-use: XSLT offers a highly abstract component based solution that can be re-
used, extended and plugged into a variety of environments where access to geospatial data is
necessary. There are no dependencies on operating systems, development languages or server
applications that are proprietary.

Extensible to other data types and services: The marine boundary case studies provide a stable
and representative set of simple feature geometries including points, lines and polygons. The
functionality of the XSLT is not tied to the marine boundary theme but is transparent and can be
extended to any spatial content that is built on simple features, and the pending GML 3.1 Simple
Features Profile. To validate the technology transfer options of this project an alternate set of
map services will be used in the development and test cycle. These data services will include
near real time ocean observations produced by a regional participant in the Integrated Ocean
Observing System (IOOS).

Enhances transport between geospatial and non-geospatial community: The GML is a highly
sophisticated XML profile. Developing a competency in it requires a large commitment that can
be reduced through the deployment of XSLT’s thus bringing greater resources of the geospatial
community to modelers, scientists and operational applications.

Advanced technologies in support of E-Government

Federal web services model and framework approaches: A fundamental part of the E-
Government framework is the utilization of the web service model that includes recognized
standards such as GML, WFS, SOAP, WSDL and UDDI. Implementing these protocols and
delivering a product through a client often requires a translation of the XML content to meet a
specific need. The W3C standard for translation services for XML is XSLT. All of the proposed
activities will test and identify hurdles to using the pertinent parts to these frameworks and offer
proposed solutions through specific functional examples.
Address a broad community need: The U.S. Commission on Ocean Policy and the U.S. Ocean
Action Plan have called for increased regional approaches to ocean governance, improved
coordination among federal, state, and local agencies, and increased access to data for better
decision making. The U.S. Commission on Ocean Policy also recommended establishing new
regional coordination bodies—called Regional Ocean Councils (ROCs). The Ocean
Commission proposed that ROCs should be supported by regional ocean information programs
that would provide easy access to spatial data and other information to inform regional decision
making. Under the Energy Act of 2005, both the DOC/NOAA and DOI Minerals Management
Service have domain responsibility for the offshore marine boundaries that impact the regions
and entire nation. The proposed transport and visualization tools directly support these
articulated needs as well as those of the IOOS community represented through the regions and
through the federal backbone.

Proposed Solution:
Project Planning and Service Preparation: The NOAA Coastal Services Center’s Ocean
Governance Team will be responsible for data acquisition from the NOAA Office of Coast
Survey, the NOAA Marine Protected Area Program, and the Department of Interior’s Minerals
Management Service. Additionally, NOAA CSC will provide the data model development and
systems and security management. Potential data themes include International Boundaries,
Jurisdictional Baselines, Territorial Waters, the Exclusive Economic Zone, Offshore Lease
Blocks, Navigation Channels, and Marine Protected Areas. The Federal Geographic Data
Committee, Marine Boundary Working Group and the Ocean Governance team will provide
assistance in use case design and agency endorsements. Definition of translation service
requirements, specifications and overall systems design will be determined when the use cases
are complete and will be documented in several UML model diagrams. These will guide the
overall development cycle and act as primary documentation. The OGC and SOAP service
deployment will use ArcIMS and ArcGIS Server. Service development will be a minor part of
the project and supported by the Ocean Governance team.

Research and Development: The objective of the development cycle is to build a suite of
XSLT’s to exchange geospatial data between two of the predominant server protocols and three
sample client environments. The servers include:

       ArcIMS with AXL and OGC-WFS/GML (a REST configuration)
       ArcGIS Server (in a SOAP configuration)

The proposed output protocols include:

       Text and HTML
       Google Maps API (JavaScript/XHTML, KML), and
       Macromedia Flash

The emphasis of the development is on effectively controlling the access to the GML and AXL
data stream. Showing the results in a sample of compelling clients is secondary and meant to be
usable for demonstration, testing and seed code for future implementations. Some development
code does currently exist from sites such as carto.net which will be used where appropriate.

Outreach and Reporting: The presentation of the project results will be delivered within the web
site of the Gulf of Mexico Legislative Atlas System. The proposed clients using the XSLT’s are
in addition to the production ArcIMS visualization clients already planned for the web site. The
contents will include sample clients to show the output of the new XSLT’s, documentation and
instruction on the XSLT design, function and steps to implement them. Access to the site is
intended to be open to the public; some restrictions may apply to the public availability of the
SOAP server because of its current status as a development host. Mid-year and end-of-year
project reports will be published and made available. A presentation will be made to the Federal
Geographic Data Committee, Marine Boundary Working Group; a poster at the ESRI Federal
User Group Meeting in Washington DC; and a presentation at NOAATech.

Analysis:

Explain the rationale for this proposed solution

   XSLT represents a concise and robust design approach to adapt GML data sources to
   numerous and ever changing client platforms; it is a recognized standard that can equally
   serve the geospatial, scientific and commercial sectors.
   The GML is broadly recognized, stable and capable of supporting sophisticated data
   structures and functionality well beyond those conventionally implemented.
   Text/HTML, Google Maps and to a lesser degree Macromedia Flash represent high
   consumer volume interfaces that are viable mechanisms for display of NOAA marine
   boundary and other topics including time dependent measures.
   The marine boundary community as represented through the FGDC is a highly organized and
   effective group that sees the proposed activity as an opportunity to begin sharing their
   authoritative data utilizing the very latest in standards protocols and technologies, and they
   do not see this tool as their primary or production grade outlet.
   Core project activity can begin immediately and continue with very few dependencies on
   partner priorities or resources.
   Data set level integration on the fly. Most geospatial clients handle each data theme as a
   discrete entity, where integration and analysis is conducted through multilayer analytical
   processes. XSLT does offer the possibility of integrating multiple geospatial data themes on
   demand with the result as a single discrete data layer.

Compare the selected plan with other alternatives

   Rely on the commercial clients. Over time commercial products like ArcGIS will embed the
   capacity to read GML Simple Features from a Web Feature Service. This meets a need for
   analysts who may already have access to those data sources natively; it does not help
   transition the NOAA geospatial assets beyond this specialized community. It may take years
   for other clients such as MatLab to include a native GML capability.
   Write application server code. GML translation services can be accomplished by modifying
   the application server, this however is a significantly more complex undertaking, and would
   result in a mechanism that is likely not to be as transferable and would require a greater
   commitment of upkeep.
   Develop dedicated client-side code. Similar negative drawbacks as outlined in server-side
   modifications mentioned above.
   Bulk process the GML conversion. A stand-a-lone application could translate the GML in
   bulk and make the static data available for download. This encourages inefficient storage,
   and an awkward configuration for rapidly changing data, or for users browsing very large
   archives, or archives from multiple locations. The proposed GML read capability of the core
   ArcGIS 9.2 product follows a similar approach. Functionality is planned to read static GML
   files only, and not from a dynamic service.

Explain the benefits of selected solution

   Reduced cost and need to access data through legacy file-based storage such as Shapefiles.
   Reduced cost and need for duplicate translation services dependent on multiple platforms.
   Lower entry and adoption barrier for any developers to access NOAA geospatial assets.
   Promotes the utilization of the GML and OGC/WFS standard.
   Reduces inconsistencies and unauthorized versions of marine boundary data being shared in
   static files.
   Uses the latest, best designed and most stable version of the GML, 3.1 with the Simple
   Features Profile and WFS 1.1.
   XSLT’s are highly adaptable making for an increased likelihood of transfer and adoption by
   others.
   Actual performance and functionality of a geospatial XSLT can be determined without
   putting a production grade project at risk.
   New hybrid products can be generated on the fly from one or more resources without
   expanding production or database loads.

Performance Measures:

   Adherence to schedule and deliverables
   Documentation of project results and conclusions
   Basic functionality and performance of the XSLT’s in a test configuration
   Availability of the marine boundary web service

Milestones
       Month 01 - milestone 1 Use cases, specifications, and development environment built
       Month 03 - milestone 2 Draft text/HTML translator
       Month 05 - milestone 3 Draft Macromedia Flash translator
       Month 07 - milestone 4 Draft Google Maps translator and sample clients on web site
       Month 10 - milestone 5 Final libraries of XSLT’s
Deliverables
       o Deliverable 1 Marine Boundary Web Feature Service
       o Deliverable 2 Sample visualizations clients on project web pages
       o Deliverable 3 XSLT library with documentation
       o Deliverable 4 Final report

						
Related docs
Other docs by gxe20370
Cloud Hosting - Amazon Web Services
Views: 41  |  Downloads: 2
A Web-Services Based Streaming Gateway for
Views: 8  |  Downloads: 1
Web Services User Manual
Views: 9  |  Downloads: 0
Requestor Friendly Web Services
Views: 2  |  Downloads: 0