1. OGC-compliant services and how they are used in NAS
Presented to: EES
By: Leonid Felikson, Dovel Technologies

2. Agenda What are OGC-compliant services? What is geospatial data?
What is the Open Geospatial Consortium (OGC)?
What is Geography Markup Language (GML)?
GML extension in aviation
OWS Common in FAA
Web Feature Service (WFS), Web Coverage Service (WCS) and Web Map Service (WMS)
Examples of OGC-compliant services in NAS
Q&A

3. What are OGC-compliant services?
Geospatial data is data that contains geographical references.
Open Geospatial Consortium (OGC) is an international organization that develops open standards for GIS processing and geospatial data and services.
OGC-compliant services are SOA (Web) services that are built according to the specifications set forth by the OGC.

4. What is geospatial data?
Spatial data is usually stored as coordinates and topology, and is data that can be mapped.
Spatial data is often accessed, manipulated or analyzed through Geographic Information Systems (GIS).
Most of this data is stored in different data formats, using different data models, coordinate reference systems, geometry models, etc.
Thus, sharing geospatial data has required considerable time, expertise and special software.
Geospatial data or geographic information is the data or information that identifies the geographic location of features and boundaries on Earth, such as natural (i.e. rivers, etc.) or constructed (i.e. buildings, etc.) features, oceans, and more.
We are surrounded by digital geo-enabled content. From massive legacy repositories, such as satellite archives, to real time sensor feeds, such as traffic monitors, the need is greater than ever to be able to discover, access, process, and share distributed geospatial content. However, most of this data is stored in different data formats, using different data models, coordinate reference systems, geometry models etc. Thus, sharing geospatial data has required considerable time, expertise and special software. OGC manages a consensus process in which standards for common interfaces and encodings are developed to enable users to maximize the value of past and future investments in geoprocessing systems and data. Additionally, there are three more specific classes of user needs:
1. The need to share and reuse geospatial content in order to decrease costs (avoid redundant data collection), get more or better information, and increase the value of legacy data holdings.
2. The need to choose the best tool for the job, and to reduce technology and procurement risk (i.e., the need to avoid being locked in to one vendor).
3. The need for more people with less training to benefit from using geospatial content in more applications, that is, the need to leverage investments in software and content.
These three classes of user needs suggest the following more specific needs:
The need for users to have access to geospatial content without copying and converting whole data sets. This includes:
The need for passing data and instructions between different vendor software platforms. 
The need to easily use geospatial content available in various data models, formats and coordinate systems. 
The need to visually integrate map displays from different data servers. 
The need to find and evaluate content and services held in other locations. 
The need to understand and overcome the differences between different content models.
The need to have the pieces of a solution work together. This includes:
The need to add or replace a capability in a current system, regardless of vendor, with minimal integration costs, and have it work seamlessly.
The need to understand the interoperability requirements of application domains and define architecture profiles and application design strategies for each.
The need to integrate geoprocessing Web services with mainstream Web services, and to develop "loosely coupled systems" using network-resident services.
The need to enable geoprocessing in the World Wide Web's open architecture. This includes:
The need to follow common best practices, to create 'reusable' content and components. Once users have geoprocessing, they want their systems to work together. Once their systems work together with other systems on the open network, new opportunities/needs arise that require a standards foundation:
The need to organize and fuse geospatial content with related text and on video, audio, and other media.
The need to access and process on-line sensor observations from multiple sources.
The need for Location Based Services that are portable across devices, networks, and providers.
The need to apply different symbology to the same content for different applications.
The need to take advantage of grid computing for geoprocessing applications.
The need for standards supporting e-commerce in spatial data and services.
…, typically represented by points, lines, polygons, and/or complex geographic features. This includes original and interpreted geospatial data, such as those derived through remote sensing including, but not limited to, images and raster data sets, aerial photographs, and other forms of geospatial data or data sets in both digitized and non-digitized forms.
In GIS, there are two basic spatial data types:
Vector Data
Raster Data
Geospatial Information
Geospatial information is a ubiquitous element of almost all data. Whether represented as a map or an image, encoded as an address,
zip code, or phone number, described in a text passage as a landmark or event, or any of the many other ways of representing
Earth features and their properties; geography is pervasive.
Geospatial location and time are integral to all aspects of the work in the OGC and OGC standards.
Geography is a foundational property for modeling the world in a coherent, intuitive way.
Location and time can be exploited as a unifying theme to better understand the context of most real and abstract phenomena.
Location is contextually simple and intuitive to most people. For example, people can relate to where they are on a map, follow directions to a place, readily grasping the spatial context of their local environment, and so forth. For computers to exchange geospatial data, clear definition of the location and the spatial referencing system is required.
Locations can be described by using different types of spatial referencing systems:
1. Civic locations using geographic terms or identifiers;
2. Coordinates as numeric values in a coordinate reference system.
3. Linear referencing for linearly located events and linear segments.
Civic locations may be unique identifiers or place names.
Spatial referencing with identifiers occurs when the identifier uniquely indicates a location, such as a postal code.
Place names may be ambiguous, such as “Springfield”, requiring additional information so that this place name can be resolved
into a specific location identified by coordinates.
Gazetteers and geocoding are geospatial operations or processes used to convert a place name into a geographic coordinate.
Coordinates are a sequence of N numbers designating the position of a point in N-dimensional space. Coordinates are always expressed using some coordinate reference
system (CRS). A coordinate reference system is a coordinate system that has a reference to the Earth. CRSs are defined in the OGC Abstract Specification: Topic 2 - Spatial Referencing
by Coordinates, also published as ISO This document also describes coordinate transformations and coordinate conversions between two different coordinate reference
systems. With such information, geographic data referred to different coordinate reference systems can be merged together for integrated manipulation.
A map projection is a coordinate conversion from a geodetic coordinate system to a planar surface, converting geodetic latitude and longitude to plane (map) coordinates.
The result is a two-dimensional coordinate system called a projected coordinate reference system.

5. What is the OGC?
The Open Geospatial Consortium (OGC) is a consortium of companies, non-governmental organizations (NGOs), research organizations, agencies and universities with a common vision in which everyone benefits from geographic information and services made available across any network, application, or platform.
The OGC mission is:
to promote the development and use of advanced open systems standards and techniques in the area of geoprocessing and related information technologies;
to manage a global consensus process that results in approved interface and encoding standards that enable interoperability among and between diverse geospatial data stores, services, and applications.
Systems implementing OGC standards can interoperate, whether those systems are running on the same computer or the same network or are distributed across the globe.
The Open Geospatial Consortium (OGC) has developed a member consensus that when software vendors implement their products in compliance
with open geospatial web service interface and data encoding specifications, end-users benefit from a larger pool of interoperable web based tools
for geodata access and related geoprocessing services.

6. Geography Markup Language
GML is:
a modeling language for geographic systems;
used to enable an open interchange format for geographic transactions;
focused on the description of geographic content;
relying on use of other languages and standards like KML (Keyhole Markup Language) or SVG (Scalable Vector Graphics) for graphical presentation;
using a GML schema. This allows users and developers to describe generic geographic data sets that contain points, lines and polygons.
GML is not:
a presentation standard; so it can’t be used for drawing maps;
carrying properties like line thickness or color.
Geography Markup Language (GML) is the XML grammar defined by the OGC to express geographical features.
Geographic data is concerned with a representation of the world in spatial terms that is independent of any particular visualization of that data. When we talk about geographic data we trying to capture information about the properties and geometry of the objects which populate the world about us. How we symbolize these on a map, what colors or line weights we use is something quite different. Just as XML is now helping the Web to clearly separate content from presentation, GML will do the same in the world of geography.
GML is based on the abstract model of geography developed by the OGC. This describes the world in terms of geographic entities called features (objects that represent physical entities, e.g. a building, a river, or a person).
Features distinct from geometry objects.
GML vocabularies are created by communities of interest. These vocabularies are called GML Application Schemas.
Using application schemas, users can refer to roads, highways, and bridges instead of points, lines and polygons.
Developers of GML envision communities working to define community-specific application schemas that are specialized extensions of GML.

7. Example of GML
The following GML example illustrates the distinction between features and geometry objects.
Note: The Building feature has several geometry objects, sharing one of them, the Point (with identifier p21), with the SurveyMonument feature.
<abc:Building gml:id="SearsTower"> <abc:height>52</abc:height> <abc:position xlink:type="Simple" xlink:href="#p21"/> </abc:Building> <abc:SurveyMonument gml:id="g234"> <abc:position> <gml:Point gml:id="p21"> <gml:posList>100,200</gml:posList> </gml:Point> </abc:position> </abc:SurveyMonument>

8. GML extension in aviation
OGC standards support Aviation Information Management (AIM)
Several of the world's major government aviation organizations working with large and small aviation companies are now far along in the development and adoption of the Aeronautical Information Exchange Model (AIXM), the Weather Information Exchange Model (WXXM), and the Flight Information Exchange Model (FIXM).
Because location information is critical in virtually all aviation activities, location interface and encoding standards from the OGC play an important role.

9. GML extensions used in NAS
The Aeronautical Information Exchange Model (AIXM) is based on the OGC GML Encoding Standard to ensure alignment with international standards for location information and to ease its adoption by technology providers that already support GML in their Commercial-Off-The-Shelf (COTS) products.
The Weather Information Exchange Model (WXXM) is being developed as a standard for the exchange of weather information in support of aviation meteorology (MET) domain requirements.
The Flight Information Exchange Model (FIXM) is a data interchange format for sharing information about flights throughout their lifecycle.
Because location information is critical in virtually all aviation activities, location interface and encoding standards from the OGC play an important role.
AIXM specification supports the data-centric environment. It wires aeronautical information collection, dissemination and transformation throughout the data chain.
AIXM has two main components:
The AIXM Conceptual Model is a conceptual model of the aeronautical domain. It describes the features and their properties (attributes and associations) within the domain. Therefore, it can be used as the logical basis for AIM databases.
The AIXM XML Schema is an exchange model for aeronautical data. It is an implementation of the Conceptual Model as an XML (Extensible Markup Language) schema. Therefore, it can be used to send aeronautical information to others in the form of XML encoded data, enabling systems to exchange aeronautical information.
WXXM is:
based on GML,
an implementation of the OGC Observation and Measurement Model (O&M) Encoding Standard;
is harmonized and coordinated with the World Meteorological Organization (WMO).
supporting the data-centric environment and wiring MET information collection, dissemination and transformation throughout the data chain.
WXMM has three main components:
The conceptual Information Model (WXCM)
The Logical Data Model (WXXM)
The Exchange Schema (WXXS)
FIXM increases interoperability among all air traffic stakeholders by mediating interactions between Air Traffic Management systems, airspace users, transportation authorities, security and defense authorities, logistics and transportation providers, and many more.
FIXM provides common situational awareness, facilitates incident management, and enables the use of transportation and security data in new ways previously unavailable.
FIXM simplifies the global exchange of data by providing a framework developed on international standards.
FIXM has a strong harmonization role. It provides a standardized way of communicating transportation and security data. It incorporates semantic context for the flight data it expresses, which makes it flexible: new data elements can be added to FIXM, and existing data elements can be discovered. FIXM is also modular, allowing a wide variety of system interactions while maintaining efficiency.

10. OWS Common used in FAA OGC Web Service (OWS) Common
Web Feature Service (WFS)
Web Coverage Service (WCS)
Web Map Service (WMS)

11. OWS Common used in FAA, cont’d.
OGC Web Services (OWS) Common describes common capabilities across all OGC web services.
Web Feature Service Interface Standard (WFS) provides an interface allowing requests for geographical features across the Web using platform-independent calls.
Web Coverage Service Interface Standard (WCS) defines Web- based retrieval of a coverage – that is, digital geospatial information representing space/time-varying phenomena.
Web Map Service (WMS) is a standard protocol for serving geo-registered map images over the Internet that are generated by a map server using data from a GIS database.
The WFS Web Feature Services or Web Feature Server specification supports two communication models:
Stateless Request Reply
Pub/Sub
A messaging system in which clients address messages to a specific node in a content hierarchy, called a topic. Publishers and subscribers are generally anonymous and can dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a node's multiple publishers to its multiple subscribers. Messages are generally not persistent and will only be received by subscribers who are listening at the time the message is sent. A special case known as a “durable subscription” allows subscribers to receive messages sent while the subscribers are not active. (Source:  Web Notification Service (WNS) is one of the implementation specifications for the Pub/Sub model. Regardless of the model, URL format is used and specified in the WFS specification. At this time there are no open-standard implementations of WNSs. Vendors plan to release implementations once the standard has been ratified.
Data[edit]
Main article: Geography Markup Language
Data passed between a Web Feature Server and a client is encoded with Geography Markup Language (GML), an XML dialect which can be used to model geographic features.
The version of the WFS specification requires the use of GML version 2.1.2, while the version of the WFS specification requires the use of GML version For both versions of the WFS specification, an arbitrary number of other encodings can also be defined, in addition to the required GML or format (for and respectively).
GML contains encoding support for basic geometric 'primitives': points, lines, polygons, etc.
GML contains encoding support for more advanced geometric representations: curves, surfaces, multi-dimensions (time, elevation, multi-band imagery). In addition, GML includes encoding support for topologically integrated datasets.
OWS Common
The key feature which is common to all OGC web services is an operation to describe its capabilities, including supported operations, supported protocol bindings, and advertised datasets (coverages in this case). The mandatory GetCapabilities operation allows any client to retrieve metadata about the capabilities provided by any server that implements an OWS interface Implementation Specification.
The normal response to the GetCapabilities operation is a service metadata document that is returned to the requesting client. This service metadata document primarily contains metadata about the specific server abilities (such as about the specific data and formats available from that server).
The mandatory GetCapabilities operation allows any client to retrieve metadata about the
capabilities provided by any server that implements an OWS interface Implementation
Specification. The normal response to the GetCapabilities operation is a service metadata
document that is returned to the requesting client. This service metadata document
primarily contains metadata about the specific server abilities (such as about the specific
data and formats available from that server). This service metadata also makes an OWS
server partially self-describing, supporting late binding of clients.
A service metadata document shall be the normal response to a client from performing
the GetCapabilities operation, and shall contain metadata appropriate to the specific
server for the specific OWS. For a server with tightly coupled data that it serves or uses,
this service metadata document shall include metadata about that data. That service
metadata document shall be encoded in XML, and shall use XML Schemas to specify the
correct document contents and organization.
NOTE A specific OWS Implementation Specification or implementation can provide additional
operation(s) returning service metadata for a server. Such operations can return service metadata using
different data structures and/or formats, such as WSDL or ebRIM. When such operation(s) have been
sufficiently specified and shown more useful, the OGC may decide to require those operation(s) instead of,
or in addition to, the current GetCapabilities operation.
WFS
WFS encodes and transfers information in GML.
The current version of WFS is
The WFS standard defines the framework for providing access to, and supporting transactions on, discrete geographic features in a manner that is independent of the underlying data source.
Through a combination of discovery, query, locking, and transaction operations, users have access to the source spatial and attribute data in a manner that allows them to interrogate, style, edit (create, update, and delete), and download individual features.
The transactional capabilities of WFS also support the development and deployment of collaborative mapping applications.
Operation
Description
GetCapabilities
Generates a metadata document describing a WFS service provided by server as well as valid WFS operations and parameters
DescribeFeatureType
Returns a description of feature types supported by a WFS service
GetFeature
Returns a selection of features from a data source including geometry and attribute values
LockFeature
Prevents a feature from being edited through a persistent feature lock
Transaction
Edits existing feature types by creating, updating, and deleting
GetPropertyValue
Retrieves the value of a feature property or part of the value of a complex feature property from the data store for a set of features identified using a query expression
GetFeatureWithLock
Returns a selection of features and also applies a lock on those features
CreateStoredQuery
Create a stored query on the WFS server
DropStoredQuery
Deletes a stored query from the WFS server
ListStoredQueries
Returns a list of the stored queries on a WFS server
DescribeStoredQueries
Returns a metadata document describing the stored queries on a WFS server
It is the next logical step of by defining interfaces for data access and manipulation
operations on geographic features using HTTP as the distributed computing platform.
Via these interfaces, a web user or service can combine, use and manage geodata
-- the feature information behind a map image -- from different sources
by invoking the following WFS operations on geographic features and elements:
Create a new feature instance
Delete a feature instance
Update a feature instance
Lock a feature instance
Get or query features based on spatial and non-spatial constraints
The OGC Web Feature Service allows a client
to retrieve and update geospatial data encoded in
Geography Markup Language (GML) from multiple Web Feature Services.
The requirements for a Web Feature Service are:
1. The interfaces must be defined in XML.
2. GML must be used to express features within the interface.
3. At a minimum a WFS must be able to present features using GML.
4. The predicate or filter language will be defined in XML and be derived from CQL as defined in the OpenGIS Catalogue Interface Implementation Specification.
5. The datastore used to store geographic features should be opaque to client applications and their only view of the data should be through the WFS interface.
6. The use of a subset of XPath expressions for referencing properties.
Geographic features
The state of a geographic feature is described by a set of properties where each property can be thought of as a {name, type, value} tuple. The name and type of each feature property is determined by its type definition. Geographic features are those that may have at least one property that is geometry-valued. This, of course, also implies that features can be defined with no geometric properties at all.
Operations
To support transaction and query processing, the following operations are defined:
A web feature service must be able to describe its capabilities. Specifically, it must indicate which feature types it can service and what operations are supported on each feature type.
A web feature service must be able, upon request, to describe the structure of any feature type it can service.
A web feature service must be able to service a request to retrieve feature instances. In addition, the client should be able to specify which feature properties to fetch and should be able to constrain the query spatially and non-spatially.
GetGmlObject
A web feature service may be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs. In addition, the client should be able to specify whether nested XLinks embedded in returned element data should also be retrieved.
A web feature service may be able to service transaction requests. A transaction request is composed of operations that modify features; that is create, update, and delete operations on geographic features.
A web feature service may be able to process a lock request on one or more instances of a feature type for the duration of a transaction. This ensures that serializable transactions are supported.
Based on the operation descriptions above, three classes of web feature services can be defined:
Basic WFS
A basic WFS would implement the GetCapabilities, DescribeFeatureType and GetFeature operations. This would be considered a READ-ONLY web feature service.
XLink WFS
An XLink WFS would support all the operations of a basic web feature service and in addition it would implement the GetGmlObject operation for local and/or remote XLinks, and offer the option for the GetGmlObject operation to be performed during GetFeature operations.
Transaction WFS
A transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. Optionally, a transaction WFS could implement the GetGmlObject and/or LockFeature operations.
WCS
A coverage is the digital representation of some spatio-temporal phenomenon. Coverages play an important role in geographic information systems, geospatial content and services, GIS data processing, and data sharing.
A coverage is a special kind of geographic feature, with the distinguishing characteristics that other features have one particular value associated (such as a road number, which remains constant over all the road's extent) whereas a coverage typically conveys different values at different locations.
A coverage is represented by its "domain" (the universe of extent) and a number of range of values representing the coverage's value at each defined location. For example, a satellite image derived from remote sensing might record varying degrees of light pollution. Aerial photography, land cover data, and digital elevation models all provide coverage data. Generally, a coverage can be multi-dimensional, such as 1-D sensor time series, 2-D satellite images, 3-D x/y/t image time series or x/y/z geo tomograms, or 4-D x/y/z/t climate and ocean data. Actually, climate data sometimes occur as 5-D coverages, showing that the coverage goes beyond spatio-temporal axes.
The OGC WCS specification defines an interface for access to a generic network-accessible gridded data store.
Gridded weather data sets can be complex and are typically large in size, ranging from three-dimensional to five-dimensional. For example, satellite data is three-dimensional, with x and y coordinates and an observation time, while a forecast model run has five dimensions: x, y, z, a forecast reference time, and a valid time.
Access to the gridded weather data is tailorable, allowing a consumer to receive only pertinent data within a data set.
Data sets can be queried using spatial, temporal, and/or parametric filters, resulting in a subset of data containing only the necessary data being delivered to the consumer.
The OGC Web Coverage Service (WCS) supports electronic retrieval of
geospatial data as "coverages" – that is, digital geospatial
information representing space/time-varying phenomena.
the Web Coverage Service provides available data together with their detailed descriptions; defines a rich syntax for requests against these data; and returns data with its original semantics (instead of pictures) which may be interpreted, extrapolated, etc., and not just portrayed.
Unlike WFS, which returns discrete geospatial features,
the Web Coverage Service returns coverages representing space/time-varying phenomena
that relate a spatio-temporal domain to a (possibly multidimensional) range of properties.
As such, WCS focuses on coverages as a specialized class of features and, correspondingly,
defines streamlined functionality.
WMS
The specification was developed and first published by the Open Geospatial Consortium in 1999.[3]
An important distinction must be made between WFS and WMS, which refers to the sending and receiving of geographic information after it has been rendered as a digital image.
One can think of WFS as the "source code" to the maps that one would view via WMS.
Exceptions
If an exception occur
Retrieves metadata about the service, including supported operations and parameters, and a list of the available layers
GetMap
Retrieves a map image for a specified area and content
GetFeatureInfo (optional)
Retrieves the underlying data, including geometry and attribute values, for a pixel location on a map
DescribeLayer (optional)
Indicates the WFS or WCS to retrieve additional information about the layer.
GetLegendGraphic (optional)
Retrieves a generated legend for a map

12. OGC-compliant vs. Web services (WS*)
OGC services are defined specifically for geospatial data – Web services are data neutral.
OGC services use the uniform set of operations (methods) defined by OGC interface specifications – Web services expose an arbitrary set of operations.
OGC services require Capabilities document and stand-alone XML schema – Web services require WSDL. (Note: OGC services may use WSDL as well.)
OGC –compliant services and Web services (WS*) are both standard-based, self-describing and designed primarily for synchronous message exchange patterns.

13. How OGC services are documented
Requirements for OGC-compliant services shall be specified in Web Service Requirements Documents (WSRD).
Service descriptions shall be presented as Web Service Description Documents (WSDD).
WSDL files should be generated for all OGC-compliant services.
XML Capabilities and Feature XSD files shall also be presented.
In some cases, an External Data Description document may be provided to augment a WSDD.
All documents shall be uploaded into the NAS Registry/Repository (NSRR).
Data Gridded vs. Non-Gridded
Gridded data products are typically expressed as rectangular arrays whose elements contain a data value coinciding with uniformly spaced observations or computed results on a 2-D surface. Gridded data arrays map to the Earth’s surface through a map projection. Numerical models generate regularly-spaced grids of data values representing a large area and volume in time and space.
Non-gridded data usually expresses observations or computed results associated with singular, geospatial locations.
The gridded products are available through an OGC-based Web Coverage Service (WCS).
Non-gridded products are available through an OGC-based Web Feature Service (WFS).
The gridded products include:
 Current Continental United States (CONUS) Vertically Integrated Liquid (VIL) Dataset
 Forecast CONUS VIL Dataset
 Current Echo Tops Dataset
 Forecast Echo Tops Dataset
 Current CONUS Satellite Dataset
Non-gridded CIWS data products contain data values organized as points, curves, contours, or text messages, along with associated attributes and properties. The geospatially sparse and irregular spacing of these data lend themselves to encoding using the human-readable, text-based Extensible Markup Language (XML) format. The non-gridded products include:
 Growth and Decay Trends
 Storm Information – Echo Tops Tags
 Storm Information – Leading Edges
 Storm Information – Motion Vectors
 Forecast Standard-Mode VIL Contours
 Forecast Winter-Mode VIL Contours
 Forecast Echo Tops Contours
 Echo Tops Forecast Accuracy Scores
 Standard-Mode VIL Forecast Accuracy Scores
 Winter-Mode VIL Forecast Accuracy Scores

14. CIWS CDDS (FAA example 1)
The Corridor Integrated Weather System (CIWS) is a fully automated weather analysis and forecasting system, prototyped and operated for the FAA by MIT Lincoln Laboratory (MIT LL).
CIWS combines data from U.S. and Canadian weather radars with satellite data, surface observations, and numerical weather models to dramatically improve the accuracy and timeliness of storm severity information, and to provide accurate, rapidly updating weather information to air traffic flow managers.
CIWS benefits are allowing managers to achieve more efficient tactical use of national airspace, reduce controller workload, and significantly reduce delay.
Through the CIWS Data Distribution Service (CDDS), both NAS and non-NAS users can now obtain the CIWS gridded and non-gridded products via SWIM-compliant SOA-enabled web services.
Both request/reply and publish/subscribe interfaces to the data are available.

15. WINS WCS (FAA example 2)
Weather Information Network Service (WINS) Web Coverage Service (WCS) provides gridded weather data including the Rapid Refresh (RAP) Continental United States (CONUS), Global Forecast System (GFS), and North American Mesoscale (NAM) forecast models, as well as the Aviation Weather Center’s (AWC) Current Icing Product (CIP) and National Convective Weather Diagnostic (NCWD).
The WINS implements the OGC WCS standard which provides a highly flexible interface to potential consumers.
WINS WCS service consumers include:
Weather and Radar Processor (WARP)
CAASD Analysis Platform for En-Route (CAPER)
Surveillance and Broadcast Services (SBS)
NextGen Surface Prototype System (NSPS)
Spatial, temporal, and parametric filtering capabilities of the WCS allow the consumer to tailor the data that is received from the server. The WINS WCS supports one-time requests for data and extends the standard to include support for an underlying publish/subscribe messaging infrastructure.
The WINS WCS is deployed as a net-centric service that is compliant with the SWIM architectural approach, relying on the NAS core Enterprise Services to provide messaging, addressing, and security functionality.

16. WINS WCS, cont’d.
The WINS WCS provides business functionality to satisfy a consumer’s need for timely and accurate weather information such as numerical forecast model, icing forecast, and convective forecast data.
The service interface is a collection of types, messages, operations, and interface descriptions. It provides detail on how the WCS data is constructed independent of the messaging transmission technology.
The WINS WCS service interface is composed of two specifications:
the OGC WCS specification and
the OASIS Web Service Notification (WSN) specification.

17. References
OGC® Standards and Supporting Documents
OGC Web Services Common at
WFS 2.0 at
WCS 2.0 at
Contact Information:
Mark Kaplun, SWIM Governance Lead
Leonid Felikson

18. Q & A

19. Thank You!