Using PostgreSQL and PostGIS as a Spatial Da

advertisement

Spatial Databases: Lecture 6

DT211-4 DT228-4 Semester 2

2010

Pat Browne

Web Mapping http://www.archaeology.ie/smrmapviewer/mapviewer.aspx

http://www.openapp.ie/geospatial/demonstration

/

Firefox http://spatial.dcenr.gov.ie/imf/imf.jsp?site=GeoUrban

W3C and location

Location and geographical properties of resources has always been something of a dilemma for the World Wide

Web, which has served so well to unlink the global identity of a resource from its physical location on the globe. One of the Web's greatest values is its capacity for enabling the growth of communities which are not constrained by distance and geography. Nonetheless, physical location is at least an essential property if not a part of the identity of any real entity. When appropriate, the Local Web of resources identified by location and geography is an essential aspect of Web discovery and communication .

Joshua Lieberman, Geospatial Incubator Group Chair,

2007/10/3, http://www.w3.org/2005/Incubator/geo/

Spatial Databases must integrate with other applications and data.

HTML Viewer

Java Viewer

(Internet)

GIS Desktop

Applications

Wireless

Mobile

Devices

Network

Custom

Applications

Map Renderer

Spatial

DB

Server Side

Applications

Outline

Question: What need to be done to allow geographic data to be available on the Web?

Answer: A lot!

The a typical Open Geo-Stack:

PostGIS for persistence: We need some structured way to hold spatial & non-spatial data.

Geoserver for server side map specific function WMS,WFS.

OpenLayers for client side programming to handle user interaction.

A web service (WS) is a software system designed to support interoperable machine-to-machine interaction over a network (W3C). A WS is any service that is available over the Internet, uses a standardized XML messaging system, and isn't tied to any one operating system or programming language.

Typical web mapping service

Web Services

Web services are software services identified by a URI that are described, discovered, and accessed using Web protocols. Web Services consume and produce XML. (smart data and meta-data). Web services provide the potential to increase interoperability, application integration, which make transacting business easier.

WS technology has established a common, vendor-neutral platform for integrating distributed computing applications.

As WS proliferate, they become similar to Web pages in that they are more difficult to discover.

Semantic Web technologies will be necessary to solve the Web service discovery problem.

Typical interaction between WS components

Universal Description,

Discovery and

Integration ( UDDI ) is a platform-independent,

XML-based registry for businesses worldwide to list themselves on the

Internet.

Web Services

Description Language

( WSDL ) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint.

Web Services and the Semantic

Web

The Semantic Web will enable Web Services to interact with other Web services. Advanced Web service applications involving comparison, composition, or orchestration of Web services will require Semantic Web technologies for such interactions to be automated.

Web services are based on a platform-neutral processing model for XML. The step after that is to make both the data and the processing model smarter. In other words, continue along the

“smart-data continuum.” In the near term, this will move along five axes: logical assertions, classification, formal class models, rules, and trust.

Web Services Description language

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document

( http://www.w3.org/TR/wsdl ) describe how to use WSDL in conjunction with SOAP

1.1, HTTP GET/POST, and MIME.

Web Services Description language

As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way.

WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

Web Services Description language

1.1

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

Web Services Description language

A WSDL document uses the following elements in the definition of network services:

 Types – a container for data type definitions using some type system (such as XSD).

 Message – an abstract, typed definition of the data being communicated.

 Operation – an abstract description of an action supported by the service.

 Port Type –an abstract set of operations supported by one or more endpoints.

 Binding – a concrete protocol and data format specification for a particular port type.

 Port – a single endpoint defined as a combination of a binding and a network address.

 Service – a collection of related endpoints.

WSDL 1.1

Universal Description, Discovery, and Integration (UDDI)

The UDDI project encourages the inter operability and adoption of Web services. UDDI provides a standards-based set of specifications for service description and discovery, as well as a set of Internet-based implementations. UDDI continues to rapidly evolve and to gain industry support. The specification has developed quickly because it is backed with rapid implementation, which proves the concepts and provides a rich experience base for further refinement of the specification.

Universal Description, Discovery, and Integration (UDDI)

UDDI addresses a number of business problems. First, it helps broaden and simplify business-to-business (B2B) interaction. For the manufacturer who needs to create many relationships with different customers, each with its own set of standards and protocols, UDDI supports a highly flexible description of services using virtually any interface. For the flower shop in Australia that wants to get plugged in to every marketplace in the world but does not know how, UDDI provides a way to do this. The specifications allow the efficient and simple discovery of their business and the services they offer by publishing them in the registry.

Universal Description, Discovery, and Integration (UDDI)

Technical models, or tModels.

Universal Description, Discovery, and Integration (UDDI)

Technical models, or tModels.

Universal Description, Discovery, and Integration (UDDI)

UDDI can:

Make it possible to discover the right service from the millions currently online

Define how to enable transactions once the preferred service is discovered

Allow user-driven choice of service

Describes services programmatically in a single, open, and secure environment

Reach new user and increasing access to current users

Web services for mapping

The principle OGC web services are;

WMS; standardizes the display of map images. WMS can register and overlay maps from multiple remote sources.

WFS-T: standardizes the retrieval and update of features.

WPS: can describe calculations or processes (inputs and outputs, triggers, execution) as a Web Service. The processes can be supplied by a GIS (e.g. GRASS or special API)

WCS: standardizes access to spatially extended coverages, usually encoded in a binary format and offered by a server (typically remotely sensed data).

Web services for mapping

Web services have reached a level of sophistication that facilitates the delivery and use of spatial information. Web services for mapping enable sharing information.

Web services for mapping allow consumers and providers of information to integrate diverse data sets.

Web services for mapping

To access remote data we need specific knowledge about that data source: server address, data layers available, meta-data, required and available data format.

Once the system knows the details, application can request exactly maps and other information

We will GeoServer as our map server.

Another popular open source map server is simply called MapServer (http://mapserver.org/)

Web services for mapping

The course web site list many examples of data sharing. Many of the links show how government departments share data with the public and other departments. Which means data users don't need to store their data locally. In many cases centralizing data storage can lead to cost savings and avoid redundancy. Web services for mapping can facilitate integration, centralization and sharing.

OGC Web Map Service (WMS)

 The OpenGIS® Web Map Service Interface Standard

(WMS) provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. A WMS request defines the geographic layer(s) and area of interest to be processed.

The response to the request is one or more georegistered map images (returned as JPEG, PNG, etc) that can be displayed in a browser application. The interface also supports the ability to specify whether the returned images should be transparent which allows layers from multiple servers can be combined.

OGS’s features

Feature associated with a location relative to the Earth.

The starting point for modeling of geographic information. A feature is an abstraction of a real world phenomenon. A geographic feature is a feature associated with a location relative to the Earth. A digital representation of the real world can be thought of as a set of features.

Geographic features occur at two levels: feature instances and feature types. At the instance level, a geographic feature is represented as a discrete phenomenon that is associated with its geographic and temporal coordinates. These individual feature instances are grouped into classes with common characteristics feature types.

OGC WFS

The OGS Web Feature Service Interface Standard (WFS) defines an interface for specifying requests for retrieving geographic features across the Web using platform-independent calls. The WFS standard defines interfaces and operations for data access and manipulation on a set of geographic features, including:

 Get or Query features based on spatial and non-spatial constraints

 Create a new feature instance

 Get a description of the properties of features

 Delete a feature instance (WFS-T)

 Update a feature instance (WFS-T)

 Lock a feature instance (WFS-T)

By default, the specified feature encoding for input and output is the

Geography Markup Language (GML) which in turn is written in XML.

OGC WFS

Via the WFS interfaces, a web user or service can combine, use and manage features 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 nonspatial constraints

OGC WFS

Web Services Description

Language is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.

WFS follows the web services model

OGC WFS

Basic sequence of events

Web services for mapping

Data can be shared in a number of ways. A complete copy can be given to the remote user allowing them to use the data for any purpose.

Alternatively, a more limited form of access can be granted. For example, users of Google Map do not get the actual spatial data although they are granted a high degree of usage through the

Google Map API. OGC WMS (see later) provide to bitmap image rather than the vector map itself, whereas WFS provides vectors.

Web services for mapping

Some spatial data, such as hurricane locations, is constantly changing

(streamed). It does not make sense to download such data. It would be better to integrate the weather layer in your map that accesses a web service in realtime.

Web services can make very large data sets available to users, reducing the need for continual data storage upgrades.

Requesting a Map

GeoServer can request map data from a remote web server

Typical web map services software environment

OpenLayers is a JavaScript library for displaying map data in a web browser.

We will look at OpenLayers later

ModJK is the connector used to connect Tomcat servlet container with web servers such as Apache. We use

GeoServers servlet container called

Jetty and do not need to connect to

Apache.

GEOS (Geometry Engine, Open

Source) is a library used by

PostGIS to perform all the operations in the OpenGIS

Simple Features for SQL

Specification.

PROJ.4

is an open source library used by PostgIS to convert between geographic coordinate systems

The OGC Web Service package

Client and WFS messages

A Typical Web Page Layout

GeoServer’s architecture

MapInfo Interchange

Format (MIF) is a map and database exporting file format of MapInfo software product.

ArcSDE technology manages spatial data in a relational database management system (RDBMS) and enables it to be accessed by ArcGIS clients. It is the technology that provides the framework to support long transactions, which facilitates the versioned editing environment in multiuser geodatabases.

The JTS

Topology Suite is an API of 2D spatial predicates and functions.

GeoServer

GeoServer can access and provide data using a web services framework.

The Open Geospatial Consortium (OGC) has developed specifications for web services for mapping. The OGC aim to increase interoperability between applications by creating common interchange languages through common standards. GeoServer implements

OGC’s web mapping services.

GeoServer & OGC specifications

Web Map Service (WMS) Share and request vector and raster map data in plain image format

Web Feature Service (WFS) Share and request vector map data and attributes in GML format

Web Feature Service –Transactional (WFS-T ) is a WFS that supports transactions - add, delete, or update features.

Web Coverage Service (WCS) Share image/raster data with original data value

Web Map Context (WMC) Save and load views of a WMS application as XML

Styled Layer Descriptors (SLD) Request particular symbolization and styling from a WMS

Geography Markup Language (GML) XML-based format for spatial and tabular data interchange

Filter: Encoding XML-based format for defining queries on spatial data

GeoServer & OGC specifications

GeoServer 1.6.0 and above supports WFS 1.1

WFS 1.1 supports on the fly re-projection of data, which means data can be returned in a SRS other than the native one. We can check the WFS version as follows:

 http://localhost:8080/geoserver/wfs?request=GetCapabilities&service=WFS&version=1.0.0

Here is the XML for the reference system

<SRS>EPSG:4326</SRS>

Required WMS parameters for a

GetMap request

Serving static files within

Geoserver

On Geoserve static web files are stored in the www subfolder of the GeoServer data directory, and they are served at http:/myhost:8080/geoserver/www.

In the www folder you can store html, images and Javascript and have

Geoserver provide them on the web with

AJAX callbacks.

Using Servlets with GeoServer

Geoserver uses Jetty as a servlet container.

Jetty is an open-source embeddable web server and servlet container, written in Java.

 http://www.mortbay.org/jetty/

Jetty can handle Java servlets and

JavaServerPages (JSP) technologies and traditional static web pages.

There is a Jetty Servlet tutorial at:

 http://www.seas.upenn.edu/~cis550/jetty.html

Using Servlets with GeoServer

Each GeoServer service is provided by a specific Servlet that intercepts the client requests and builds up the response in accordance to the GeoServer configuration.

Geoserver can be deployed as a standard

WAR package inside Java Servlet containers.

Configuration Interface

Managing a Geographic Database

From Mobile Devices Through

OGC Web Services

The OGS’s Spatial Web

Universal Description,

Discovery and

Integration ( UDDI ) is a platform-independent,

XML-based registry for businesses worldwide to list themselves on the

Internet.

The OGS’s Spatial Web

Web Feature Service

•A WFS must implement the following operations:

•GetCapabilities - queries the WFS service to determine available options.

•DescribeFeatureType - retrieves the XML schema to allow the WFS client to parse the result sets.

•GetFeature - performs the actual query - parameters such as bounding box and any other filters should be passed in, as appropriate, and the WFS service then returns a GML result set containing full geometry and feature attributes.

OpenLayers

OpenLayers

OpenLayers (OL) is an open source JavaScript library for displaying map data in web browsers. OL provides an

API for building complex web-based geographic applications. Data can be combined from a number of sources without requiring any server side processing as layers can be assembled and rendered on the client.

Client side programming includes panning and zooming of maps, client-side tiling, markers, popup windows, various adjustable navigation components, keyboard commands, an event handling mechanism and client server communications. Each part of OL is configurable.

OL can act as a Web Client for

See; http://www.bostongis.com/?content_name=openlayers_tut_01

OpenLayers

OL can act as a Web Client for:

1. OGC web services (WFS-T,WMS, and WCS

(XML.GML)),

2. Commercial services such as Google Maps(KML),

MSN Virtual Earth, ESRI products

3. Cpen source initiatives or defacto standards such as

Geographically Encoded Objects for RSS feeds

(GeoRSS). The OL GeoRSS parser will automatically connect an information bubble to the map markers, similar to Google maps.

OpenLayers

OL helps integrates a diverse set of heterogeneous data sources

(e.g. shape file and database). A variation on OL is Mapbulider built into GeoServer which supports OGC WFS and WMS.

OL facilitates a client-side JavaScript "map -mashup” style application; A mash-up is a Web application that combines data from one or more sources into a single integrated tool. The term

Mashup implies easy, fast integration, frequently done by access to open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data from Google Maps to add location information to real estate data, thereby creating a new and distinct Web service that was not originally provided by either source.

OpenLayers

OL can return projection information. A projection is a way of converting geographic coordinates (latitude and longitude) into a plane (Irish National Grid).

OL supports any projection, but needs PROJ4 for OL for projections on the fly. OL can request form map servers data in a particular projection. Strong support for the Spherical

Mercator projection used by Google Map, Open

Street Map, and Virtual Earth.

OpenLayers

Two ways of getting data.

In one mode OL can request new data without refreshing an entire document, requests can be made to any origin. Another way to retrieve data from a server is to update the location of a document in a frame. These types of requests can also be made to any origin. However, the code running in the original document is restricted to reading data in documents that come from the same origin.

OpenLayers uses AJAX

Underlying technology

The basic technology is Asynchronous JavaScript and XML

(AJAX) which includes of JavaScript and XML. XML is the W3C recommended standard for creating formats and sharing data on the

Web

OL normally uses XML for data interchange (though JavaScript

Object Notation (JSON) can be used as an alternative). Ajax is a way of developing Web applications that combines:

XHTML and CSS standards based presentation

Interaction with the page through the DOM

Data interchange with XML and XSLT

Asynchronous data retrieval with a XMLHttpRequest object which is used to read or send data on the server asynchronously.

JavaScript to tie it all together

OpenLayers uses AJAX

The Ajax interpreter works within the Web browser

(through JavaScript and the DOM) to render the Web application and handle any requests that the user might have of the Web server. Because the Ajax runtime is handling the requests, it can hold much of the information in the Ajax environment, while allowing the interaction with the application and the customer to happen asynchronously and independently of any interaction with the server. This allows the browser to handle a lot of the map processing locally without reference to the server e.g. display, rendering, scaling, querying.

OpenLayers uses AJAX

Asynchronous data transfers through the XMLHttpRequest object.

This allows websites to be refreshed in the background instead of having to be re-loaded after every modification. Because of this technology, a web mapping application is able to execute a user’s command in a fairly short time period, as the necessary steps can be completed in the background. As a result, the usability of interactive web mapping applications is approaching the features of classic Desktop (GIS) applications. The processing of web page formerly was only server-side, using web services or PHP scripts, before the whole page was sent within the network. But Ajax can selectively modify a part of a page displayed by the browser, and update it without the need to reload the whole document with all images, menus, etc... For example, fields of forms, choices of user, may be processed and the result displayed immediately into the same page.

OpenLayers Security

Browsers execute JavaScript code in a sandbox, a sealed environment with little or no access to the computer’s resources. In general OL uses AJAX security features. All communication initiated by OpenLayers.

Request methods are restricted to the same origin policy: requests may only be issued with the same protocol, to the same domain, and through the same port as the document the code is running from. This is because of the underlying JavaScript security model.

JavaScript programs have control over their own page inside the browser, but that is where their abilities end.

The underlying AJAX security can limit interaction; this can be circumvented using proxy server.

Example of OL usage

<html>

<head>

<script src = "http://www.openlayers.org/api/OpenLayers.js"></script>

<script type = "text/javascript"> function test_Map_Zoom(t) t.plan(1); var map = new OpenLayers.Map("map"); var layer = new OpenLayers.Layer.WMS("ABC",

"http://example.com/123",

'layers':'test'); map.addLayer(layer); map.zoomTo(0); t.eq(map.zoom, 0, "Map zoomed to level 0 correctly.");

</script>

</head>

<body>

<div id="map" style="width: 512px; height: 512px;"/>

</body>

</html>

Example of OL layers

Osmarender is a rule-based rendering tool for generating SVG images of OSM data. It takes as its input an OpenStreetMap dataset and a rules file. It outputs an SVG image that is marked up in accordance with the styles defined in the rule file.

Mapnik is the Open Source map renderer which we use to render the main Slippy Map layer for OSM. The slippy map is an AJAX component. JavaScript runs in the browser, which dynamically requests tiles from the server in the background (without reloading the whole HTML page) to give a smooth slippy zoomy map browsing experience. The implementation of this is mostly provided by OpenLayers.

CycleMap contains cycling specific information, lanes, routes, networks.Cycle routes are named or numbered or otherwise signed routes , which may go along roads or dedicated cycle paths.

Example of OL code

var DITKevinStreetLat=53.338

var DITKevinStreetLon=-6.268

var zoom=16 var map2; function init() { map2 = new OpenLayers.Map ("map2", { controls:[ new OpenLayers.Control.Navigation(), new OpenLayers.Control.PanZoomBar(), new OpenLayers.Control.LayerSwitcher(), maxExtent: new OpenLayers.Bounds(-20037508.34,-0037508.34,

20037508.34,20037508.34), maxResolution: 156543.0399, numZoomLevels: 19, units: 'm', projection: new OpenLayers.Projection("EPSG:900913"), displayProjection: new OpenLayers.Projection("EPSG:4326")} ); layerMapnik = new OpenLayers.Layer.OSM.Mapnik("Mapnik"); map2.addLayer(layerMapnik); layerCycleMap = new OpenLayers.Layer.OSM.CycleMap("CycleMap"); map2.addLayer(layerCycleMap); var lonLat = new OpenLayers.LonLat(DITKevinStreetL, DITKevinStreetL).transform(new

OpenLayers.Projection("EPSG:4326"), map2.getProjectionObject()); map2.setCenter (lonLat, zoom); }

OpenLayers Core Classes

OpenLayers.Map: is the main class of the OpenLayers API. It compiles the application's main map and provides numerous methods for the administration of the map display, including the display of layers and operating components, zooming and panning. In addition, this class allows for queries of current map status through numerous 'get' methods.

OpenLayers.Layer: All map displays are based on the Layer class. Layer.js produces individual layers, sets the transparency and resolution of each, and provides the basic 'get' methods.

OpenLayers.Control: Operating elements in OpenLayers are elements related to map navigation as well the display of map information (e.g. scale). The Control class serves as a base class for all operating elements, among them:Ajax avoids the traditional

Web client/server/web-page interaction between the customer and the server.

OpenLayers Core Classes

OpenLayers.Events: takes over the event handling from

OpenLayers.

OpenLayers.Pixel: displays monitor coordinates in n x- and y- pixel values.

OpenLayers.Size: displays a pixel size value pair in width and height.

OpenLayers.LonLat: displays geographic coordinates in longitude and latitude.

OpenLayers.Bounds: displays a rectangular area (bounding box) whose four sides (left, below, right, above) are indicated with geographic coordinates in float format. The Bounds class provides different get-functions (e.g. center and pixel dimensions of the bounding box) as well as comparative functions (e.g. whether a pixel is located within the defined bounding box).

OpenLayers.Util: contains the different functions and settings which cannot be assigned to any of the other OpenLayers classes.

OpenLayers Core Classes

OpenLayers.Events: takes over the event handling from

OpenLayers.

OpenLayers.Pixel: displays monitor coordinates in n x- and y- pixel values.

OpenLayers.Size: displays a pixel size value pair in width and height.

OpenLayers.LonLat: displays geographic coordinates in longitude and latitude.

OpenLayers.Bounds: displays a rectangular area (bounding box) whose four sides (left, below, right, above) are indicated with geographic coordinates in float format. The Bounds class provides different get-functions (e.g. center and pixel dimensions of the bounding box) as well as comparative functions (e.g. whether a pixel is located within the defined bounding box).

OpenLayers.Util: contains the different functions and settings which cannot be assigned to any of the other OpenLayers classes.

Mapbuilder

Mapbuilder is a client-side Javascript library for putting mapping in a web page, using an AJAX style of interaction. It works by retrieving XML data from the various sources and rendering that using the browser's built in XSL processor, so the initial HTML page never has to reload.

Server-side requirements are minimal: at minimum an HTTP server, at most 2 other server scripts which are provided (for PHP and J2EE environments).

Web Map Context File

<ViewContext>

<General>

<Window width="500" height="285" />

<BoundingBox SRS="EPSG:4326" minx="-179.14734" miny="17.884813" maxx="179.77847000000006" maxy="71.35256064399981" />

<Title>g4wd:st99_d00 Map</Title>

<KeywordList>

<Keyword>g4wd:st99_d00</Keyword>

</KeywordList>

<Abstract></Abstract>

</General>

<LayerList>

<Layer queryable="1" hidden="0" >

<Server service="OGC:WMS" version="1.1.1" title="g4wd:st99_d00 Preview" >

<OnlineResource xlink:type="simple" xlink:href="../wms" />

</Server>

<Name>g4wd:st99_d00</Name>

<Title>g4wd:st99_d00</Title>

<SRS>EPSG:4326</SRS>

<FormatList><Format current="1" >image/png</Format></FormatList>

</Layer>

</LayerList>

</ViewContext>

Web Map Context File

The OGC Web Map Context File

The Context file defines the viewable

Non-spatial attributes of the map such as the size and the title. It also identifies the data layers that should be included on the map.

Web Map Context File

The Context file is an OGC standard that can be shared across server implementations. Write this file once, and it is reusable from one server to the next.

The newer OWS Context documents support WFS and WCS layers as well as

WMS layers.

Web Map Context

OGS Web Map Context (WMC) Implementation

Specification is a companion to the OGC Web

Map Service, it describes how to save a map view comprised of many different layers from different Web Map Servers. A 'context' can be encoded and saved so that Web maps created by users can be automatically reconstructed and augmented by the authoring user or other users in the future. A Context document is structured using eXtensible Markup Language (XML).

OGC Web Services (OWS) Context

Document

Visualization

Application or Tool A

Shareable content, session, area of interest

Context Visualization

Application or Tool B

WMS WMS WMS WMS

A WPS can be configured to offer any sort of GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another

(e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network, or available at the server.

This interface specification provides mechanisms to identify the spatially-referenced data required by the calculation, initiate the calculation, and manage the output from the calculation so that it can be accessed by the client. This Web Processing Service is targeted at processing both vector and raster data.

Openlayers

Openlayers

Geoserver

OWS

WMS WFS

WMS WFS

Openlayers

Many formats for Layers

OGC WFS

GeoRSS

CSV

GML

KML

WKT

Vector

Layers, points, lines, polygons rendered with SVG

/ VML

OGC WMS

Google Maps

MSN Live

Local

Yahoo! Maps

Multimap

 ka-Map

WorldWind

Raster

Layers, tiled

WPS Operations

GetCapabilities – This operation allows a client to request and receive back service metadata (or Capabilities) documents that describe the abilities of the specific server implementation. The

GetCapabilities operation provides the names and general descriptions of each of the processes offered by a WPS instance.

This operation also supports negotiation of the specification version being used for client-server interactions.

DescribeProcess – This operation allows a client to request and receive back detailed information about the processes that can be run on the service instance, including the inputs required, their allowable formats, and the outputs that can be produced.

Execute – This operation allows a client to run a specified process implemented by the WPS, using provided input parameter values and returning the outputs produced.

WPS Example

Consider the case of a process that can intersect two polygons. The response to a GetCapabilities request might indicate that the WPS supports an operation called ―intersect, and that this operation is limited to intersecting one polygon with a second polygon. The response to a DescribeProcess request for the ―intersect process might indicate that it requires two inputs, namely: ―FirstPolygon and ―SecondPolygon, and that these inputs must be provided in

GML 2.2. Furthermore, the process will produce one output, in either

GML 2.2, or GML 3.1, and it can be delivered as a web-accessible resource.

WPS Example (continued)

The client would run the process by calling the Execute operation, and might choose to provide the two input polygons embedded directly within the request, and identify that the output should be stored as a web-accessible resource. After completion, the process would return an ExecuteResponse XML document that identifies the inputs and outputs, indicates whether or not the process executed successfully, and if successful, contains a reference to the webaccessible resource.

WPS Interaction Diagram

What WPS does

Describes the service interface, it specifies a request/response interface that defines how to:

 encode requests for process execution

 encode responses from process execution

 embed data and metadata in process execution inputs/outputs

 reference web-accessible data inputs/outputs

 support long-running processes

 return process status information

 return processing errors

 request storage of process outputs

Description Logics

Two basic knowledge representation approaches,

1. logic-based formalisms and

2. cognitive representations (using semantic networks and frames)

Logic-based systems were considered to be more powerful, network systems to be more practical.

Description Logics (DLs) are a fusion of 1 & 2.

In DL logic-based constructs are used to establish a basic terminology of the domain of discourse.

Description Logics are a family of languages, each with their own set of constructs. The basic notions of DLs draw upon first order predicate logic. They are concepts

(unary predicates) and roles (binary relations).

Example Ontology

Download