AFWWS Engineering Council
               GIS Architecture Guidance
                      Revision A




                  ...
Revision History
  Revision        Date        Explanation of Change                              Affected
               ...
Introduction. The demand for METOC data in GIS-compatible formats has recently
become a very high priority. The data that ...
WMO format, or XML format. The conversion overhead is only encountered when a
GIS-formatted data request is made, and the ...
METOC Database

                      External Users                                                              METOC Se...
services will be implemented via standard protocols (HTTP, SOAP, XML). By way of
example (support for GeoTIFF is yet to be...
exchange, but merely confines it to the weather user community. There are some caveats
that apply to the establishment of ...
Upcoming SlideShare
Loading in...5
×

AFWWS Engineering Council - GIS Architecture Guidance

319

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
319
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "AFWWS Engineering Council - GIS Architecture Guidance"

  1. 1. AFWWS Engineering Council GIS Architecture Guidance Revision A -1- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  2. 2. Revision History Revision Date Explanation of Change Affected Pages Initial release 24 Mar 05 Initial release after review of AFW Architecture All Council A 1 Sept 05 Updated to incorporate Open Geospatial 3-5 Consortium (OGC) protocol support. Table of Contents -2- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  3. 3. Introduction. The demand for METOC data in GIS-compatible formats has recently become a very high priority. The data that is being requested typically is data that we currently provide to customers in non-GIS formats. Although the METOC data is available today, the GIS format standards to be utilized are not currently specified and the AFWWS architecture to incorporate GIS has not been defined. For over five years an effort has been underway to standardize METOC data, and more recently, to provide a standard web services delivery mechanism consistent with the Net- Centric Operations and Warfare (NCOW) and C2 Enterprise Reference Architecture (C2ERA) directives. The requirement to deliver METOC data in GIS formats represents an extension of that overall NCOW/C2ERA transformation effort. In order to meet the above needs, the following areas are addressed: • Which GIS formats should be supported • A detailed AFWWS software architecture that supports use of GIS technology • GIS conversion web services Which GIS Formats Should Be Supported. The complete list of GIS formats that needs be supported is yet to be determined. One GIS data format that will be supported by JMBL is the ESRI Shape File format, an industry standard format for encoding vector GIS data. Support for other GIS data formats will be determined based on a more complete analysis of customer requirements, industry standards, DoD and Air Force standards, Navy METOC GIS support requirements, and an analysis of development resource requirements, and priorities. JMBL Support for GIS. The current METOC data standardization efforts and Service Oriented Architecture (SOA) implementation are the result of a conscious effort to implement the NCOW and C2ERA directed protocols and access methods to deliver weather data to the warfighter. In order to accommodate the demand for GIS-formatted data the SOA must be expanded to accommodate these new requirements. Consistent with directives that mandate the use of web services for COI data access, the architecture espouses the use of web services to access METOC data formatted in standard GIS formats or WMO standard formats. The METOC Community Of Interest (COI) has specified the Joint METOC Broker Language (JMBL), an XML schema and Web Services Definition Language (WSDL) specification, to accommodate data requests for METOC data. We are recommending a modification to the JMBL specification to include GIS formats as allowable output formats (e.g. ESRI Shape File format). When a request is made for GIS-formatted data (via a standard JMBL request), that request is recognized as a service that requires an auxiliary data formatting service, and is handed off to the appropriate GIS-formatting web service. The GIS-formatting service in turn retrieves the “raw” data from the METOC database (via a JMBL web service), performs the reformatting service, and returns the resulting GIS-formatted data. The original web service request is completed by replying with the GIS-formatted data. This approach strongly supports the net-centric access model and provides the data to the war-fighter in the requested format, regardless of whether the requestor wants the data in GIS format, -3- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  4. 4. WMO format, or XML format. The conversion overhead is only encountered when a GIS-formatted data request is made, and the need for data duplication between a Joint METOC Conceptual Data Model (JMDCM) compliant database and a GIS database is eliminated. As the demand for GIS data increases additional GIS enterprise services and infrastructure can be developed to meet the demands. This approach supports the continuing effort to standardize and implement a Joint METOC Conceptual Data Model (JMCDM) compliant database, and is very responsive to the more immediate demands to provide certain METOC data in GIS formats. This approach is also consistent with the Service Oriented Architecture (SOA) espoused by the NCOW/C2ERA directives. Open Geospatial Consortium Protocol Support. The Open Geospatial Consortium (OGC) is the recognized international standards organization that is leading the development of standards for geospatial and location-based services. Although the OGC standards are moving in the direction of XML and SOAP-based Web Services, many of the existing OGC standards are not Web Services Interoperability Organization (WS-I) compliant. However, these GIS standards are pervasive, and it is important that support is provided for some of these standards. The AFWWS Engineering Council has made the recommendation that these standards should be supported. One of the challenges associated with supporting the OGC standard interfaces is that the requests must be satisfied in a manner that preserves the integrity of the “one theater, one forecast” concept. For example, if a request is made for forecast winds the METOC business rules must be invoked to determine which model would be most appropriate to satisfy that generic request. Based upon availability of data, timeliness, model of consistency, resolution, area coverage, atmospheric level, and other factors the METOC business rules would be invoked to make the choice of the “best data”. The “best data” is then used to create the image that will be used for the response to the request. Business rules apply to all METOC data queries that have the potential of providing multiple responses. Some METOC data, for example surface observations, may not require the invocation of business rules (at least for area requests). The recommended architecture to provide support for the OGC protocols is illustrated in Figure 1 below. The OGC Proxy will intercept OGC requests, parse the request, and invoke the METOC business rules if necessary. Based upon the result of the rules the request will be modified and forwarded to the appropriate OGC Protocol Server. The response from the server will be returned to the requestor to satisfy the original request. This approach will both preserve the standard OGC protocol standards for the external users and preserve the integrity of the “one theater, one forecast” METOC services. Common business rules should be maintained between the JMBL METOC services and the GIS METOC services in order to maintain a consistent set of METOC services. -4- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  5. 5. METOC Database External Users METOC Services • Web Service Interface Conversion Services • Format Conversions • Business Rules • Interpolation • JMBL Parsing • Decimation • METOC Segments • Derived Parameters Intel Customer • Product Builds Mission Planning • Unit Conversions JMOBS • Projection Conversions C2 Customer • Other Services JMBL JMGRID •GIS Format Conversion Web Services GI&S OGC JMAN Customer WMS .. GIG GIG JMBL . JMxxx Rules HTTPS HTTPS Human Interface JMBL OGC ---------- ---- -- Protocols JMBL Note: HTTPS HTTPS Dissemination components intentionally left off to simplify diagram. Web Server GIS Toolkit HTTPS OGC Proxy Web Server OGC Protocol Server(s) JMBL GDB GIS Production HQ AFWA Human Interface ---------- ---- -- Weather Users GDB = GeoDatabase (e.g. ArcIMS, ArcSDE, or ArcGIS Server) Other Weather Nodes OGC = Open Geospatial Consortium Figure 1. AFWWS Software Architecture Supporting GIS GIS Conversion Web Services. In order to implement the architecture depicted in Figure 1, a new set of web services will have to be developed to provide the interface between the core METOC web services and the GIS conversion web services. These “conversion web services” will not be exposed to external users, but will be used internally to implement a loosely coupled interface to all of the enterprise services that implement the conversions necessary to meet the mandates of the mediation services demanded by our customers. GIS conversion services will simply be the first of many data conversion services that will eventually be implemented. The conversion web -5- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  6. 6. services will be implemented via standard protocols (HTTP, SOAP, XML). By way of example (support for GeoTIFF is yet to be determined), these conversion web services could be used to request the transformation of a GRIB file to GeoTIFF format. That web services exchange would proceed as follows: 1. Customer requests gridded data in GeoTIFF format (common GIS format). 2. METOC Server validates request and retrieves raw data (GRIB format). 3. METOC Server requests format conversion (from GIS Conversion Server). 4. GIS Conversion Server converts GRIB data to GeoTIFF file format. 5. GIS Conversion Server returns GeoTIFF formatted file to METOC Server. 6. METOC Server satisfies original request with GeoTIFF formatted file. Utilizing conversion web services would enable the METOC Server to accommodate requests for data that required format conversions, interpolation, decimation, derived parameters, product builds, unit conversions, projection conversions, and other data conversion services. The syntax of the conversion web service request would include an identification of the requested conversion service (e.g. please convert this GRIB file to a GeoTIFF file), and the data to be converted. The response syntax would include a request completion status and the output data or product. Weather Community Support. It is recognized that we serve two classes of end users – the weather users and the external C2 users. As a member of the METOC Community of Interest (COI), we have the responsibility to provide the non-weather user community with a consistent “best” answer. We also have the mandate to provide a well- documented set of web services to access those weather data and products (JMBL). GIS- formatted data is not an exception. From an architecture point of view, support for GIS- formatted data to the non-weather users is a straight-forward extension of the existing JMBL web services. This will require a modification to JMBL to support the specification of GIS-formatted output, but does not mandate a complete paradigm shift. Support for GIS will be implemented as conversion web services that are loosely coupled to the core METOC web services (see Figure 1 – AFWWS GIS Support Architecture). Because the GIS conversion services are loosely coupled, they can be implemented using any appropriate technology. However, the weather user has a requirement to access all of the raw data and should have access to all data and products. As we expand the availability of GIS data and products it will be desirable to promulgate that data throughout the weather community. Utilizing GIS technologies it may be desirable to expose geodatabases within the weather user community in order to increase the ability to share weather data and products. The GIS architecture recommended herein does not prevent that tightly-coupled data -6- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A
  7. 7. exchange, but merely confines it to the weather user community. There are some caveats that apply to the establishment of the geodatabases, however. Geodatabases that support the recommended architecture must adhere to the following premises: • Geodatabases are intended to be temporary data caches • Geodatabases are not intended to duplicate the contents of METOC databases • Geodatabases may be populated to facilitate GIS format conversion • Geodatabases may be populated to facilitate creation of GIS-formatted products • Geodatabases may be implemented as GIS-formatted product caches Recommendation. This paper describes the AFWWS Engineering Council recommended software architecture for incorporation of GIS technologies that all systems within the AFWWS should follow. -7- AFWWS Engineering Council GIS Architecture Guidance September 1, 2005 Revision A

×