Geospatial XSL Transformations and Web Services for
Document Sample


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
Get documents about "