Spatial Databases: Lecture 6

Spatial Databases: Lecture 6
DT211-4 DT228-4 Semester 2 2010 Pat Browne Web Mapping Firefox

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,

Spatial Databases must integrate with other applications and data.
HTML Viewer Java Viewer GIS Desktop Applications (Internet) Wireless Mobile Devices Network Custom Applications Diagram from Will Shaw How does Physical Space relate to Cyberspace? Atlas of Cyberspace by Rob Kitchin (Author), Martin Dodge (Author) Linked: How Everything Is Connected to Everything Else and What It Means (Paperback) by Albert-Laszlo Barabasi (Author) Mapping Cyberspace (Paperback) by Martin Dodge (Author) 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. Web services are software services identified by a URI that are described, discovered, and accessed using Web protocols.

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
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. Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet.

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( describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

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:

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. XSD (XML Schema Definition), a W3C Recommendation, specifies how to formally describe the elements in an Extensible Markup Language (XML) document. This description can be used to verify that each item of content in a document adheres to the description of the element in which the content is to be placed. In general, a schema is an abstract representation of an object's characteristics and relationship to other objects. An XML schema represents the interrelationship between the attributes and elements of an XML object (for example, a document or a portion of a document). To create a schema for a document, you analyze its structure, defining each structural element as you encounter it. For example, within a schema for a document describing a Web site, you would define a Web site element, a Web page element, and other elements that describe possible content divisions within any page on that site. Just as in XML and HTML, elements are defined within a set of tags.

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.

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.

The Figure illustrates how a UDDI registry is populated with data and how customers discover and use this information. A UDDI registry is built on the data provided by its customers. There are several steps to making data useful in UDDI. As shown in step 1, publishing useful information to the registry begins when software companies and standards bodies define specifications relevant to an industry or business, which they register in UDDI. These are known as technical models, or more commonly as tModels. Technical models, or tModels.

Figure 2 illustrates the UDDI message transport, from the client's SOAP request over HTTP to a registry node and back. The registry server's SOAP server handles the UDDI SOAP message, processes it, and returns a SOAP response to the client. As a matter of registry policy, client requests that entail modifying data are required to be secured and authenticated transactions. Technical models, or tModels.

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). The OGC Web Processing Service (WPS) is designed to standardize the way that GIS calculations are made available to the Internet. WPS can describe any calculation (i.e. process) including all of its inputs and outputs, and trigger its execution as a Web Service. WPS supports simultaneous exposure of processes via HTTP GET, HTTP POST, and SOAP, thus allowing the client to choose the most appropriate interface mechanism. The specific processes served up by a WPS implementation are defined by the owner of that implementation. Although WPS was designed to work with spatially referenced data, it can be used with any kind of data.

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.

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 (

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. See OGC:

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 geo-registered 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. See OGC:

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. 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. Geographic Objects The vision for the Geographic Objects Initiative is to define platform-independent and implementation-neutral interface models of specific geographic services or component objects. See Geographic Objects : The vision for the Geographic Objects Initiative is to define platform-independent and implementation-neutral interface models of specific geographic services or component objects.

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. See OGC: The OGC Glossary at Defines a geographic feature as: geographic feature 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. Geographic Objects The vision for the Geographic Objects Initiative is to define platform-independent and implementation-neutral interface models of specific geographic services or component objects. See

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 non-spatial constraints See OGC: The OGC Glossary at Defines a geographic feature as: geographic feature 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. Geographic Objects The vision for the Geographic Objects Initiative is to define platform-independent and implementation-neutral interface models of specific geographic services or component objects. See

WFS follows the web services model
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. See OGC: The OGC Glossary at Defines a geographic feature as: geographic feature 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. Geographic Objects The vision for the Geographic Objects Initiative is to define platform-independent and implementation-neutral interface models of specific geographic services or component objects. See WFS follows the web services model

Basic sequence of events
OGC WFS Basic sequence of events

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. For an example of web service usage, see:

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.

GeoServer can request map data from a remote web server
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
The communication between client and server is achieved via the HTTP protocol over a heterogeneous network, such as the World Wide Web, either through the GET or POST methods. Both services have a GetCapabilities request that provides service level information available about the WMS/WFS. In a GET request, the service that the client requires is specified through key value pairs (KVPs) in the URL of the request. In a POST request, the content of the request is encoded in XML and passed to the server through the POST-BODY of the request header.

Client and WFS messages

A Typical Web Page Layout
Apache httpd and Apache Tomcat can be served from the same port (normally Tomcat runs on port 8080 and httpd on 80), this is done using a linking program called mod_jk that informs Apache httpd that certain requests are routed to Apache Tomcat

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 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: Here is the XML for the reference system <SRS>EPSG:4326</SRS> Many WFS 1.0 servers available on the internet will return geographic coordinates in longitude/latitude order (often using EPSG 4326). The geographic and cartographic traditional order is the opposite: first latitude, then longitude The WFS 1.0 and WMS 1.1 specifications waren't clear about which axis order was supposed to be used, and as a result everybody adopted the one commonly used in GIS (longitude/latitude order) system. The WFS 1.0 ways to specify an EPSG code where or EPSG:xxxx, nor syntax seemed to mandate a clear axis order. The WFS 1.1 specification mandates the usage of the the urn:x-ogc:def:crs:EPSG:xxxx, which is specified as to something respecting "the authority axis order". In the case of the official EPSG database, that axis order is always latitude/longitude for geographic data. In order to be certified compliant with WFS 1.1 a server has to use that way of specifying an SRS name in the capabilities, making latitude/longitude the default axis order for all requests.

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 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. Jetty can handle Java servlets and JavaServerPages (JSP) technologies and traditional static web pages. There is a Jetty Servlet tutorial at: Tomcat can be used instead of Jetty as a servlet container. Tomcat+Geoserver+Apache can all be used together. Tomcat can be configured as a stand-alone TCP/IP server that communicates with Apache via mod_jk.

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
See: Managing a Geographic Database From Mobile Devices Through OGC Web Services Nieves R. Brisaboa1, Miguel R. Luaces1, Jose R. Parama1, and Jose R. Viqueira

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 Spatial Web : An Open GIS Consortium (OGC) White Paper

The OGS’s Spatial Web The Spatial Web : An Open GIS Consortium (OGC) White Paper

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.

The diagram shows how WFS relates to other OGC specification, how an actual WFS relates to its local software environment and the internal map server (e.g. GeoServer view). Student should provide at least the local software view and the OGC view.

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;

OpenLayers OL can act as a Web Client for:
OGC web services (WFS-T,WMS, and WCS (XML.GML)), Commercial services such as Google Maps(KML), MSN Virtual Earth, ESRI products 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 -mash-up” 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. JavaScripts cannot read or write files on users' computers. They cannot create files on the server (except by communicating with a server side script that creates files for them). The only thing they can store on the user's computer are cookies. They are allowed to interact with other pages in a frameset, if those frames originate from the same Web site, but not if they originate from another Web site (the postMessage method from HTML 5 does safely extend this capability). Some browsers will even treat different port numbers on the same server as a different Web site. JavaScript cannot be used to set the value attribute of a file input, and will not be allowed to use them to upload files without permission. JavaScript cannot read what locations a user has visited by reading them from the location object, although it can tell the browser to jump back or forward any number of steps through the browser history. It cannot see what other Web pages the user has open. JavaScript cannot access the cookies or variables from other sites. It cannot see when the user interacts with other programs, or other parts of the browser window. It cannot open windows out of sight from the user or too small for the user to see, and in most browsers, it cannot close windows that it did not open.

Example of OL usage <html> <head>
<script src = " <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", " '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> Line 3: A single script element loads the library from the Internet. Using the latest official release of OL rather than a local copy. This avoids keeping up with bug fixes and feature enhancements. Using this technique the developer always latest version of the API with each page view. On the other hand storing a copy of OL on the local server could improve performance, and minimize bandwidth consumption over an expensive WAN link, or the developer may choose to lock in the feature set of a specific version of the library. Or the developer may have their own version OL with specific features e.g. Developer may wish to create their own much smaller version OpenLayers version, suitable for limited applications.

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( , , , ), maxResolution: , 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); } The OSM layer is available in EPSG: Spherical Mercator which describes coordinates in meters in x/y. (AKA EPSG:3785). WGS84(Ellipsoid), uses the identifier EPSG:4326, which describes maps where latitude and longitude are treated as X/Y values. We often need to transforms from EPSG:4326 to EPSG: and from EPSG: to EPSG:4326 The coordinates you use in the Google Maps API and which are presented to the users is Latitude/Longitude in WGS84 Datum ( EPSG:4326). But for map publishing in the form compatible with all the popular interactive maps and especially for ground tile overlays you need to use Mercator map projection. Interactive web maps are using "Spherical Mercator" system which uses Mercator projection on the sphere instead of WGS84 ellipsoid. It is defined as EPSG: or EPSG:3857 (deprecated EPSG:3785). Details about this system are part of Virtual Earth documentation as well as OpenLayers documentation. Exact numeric definition for GIS systems (in formats like WKT or Proj4), is available in the SpatialReference.org on-line database.

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.

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=" " miny=" " maxx=" " maxy=" " /> <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

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

Geoserver

OWS The OGC Web Services (OWS) suite includes three principal types of georeferenced information access services: Web Map Server (WMS), Web Coverage Server (WCS), and Web Feature Server (WFS). In addition, there are services such as GeoParser and GeoCoder that return spatially referenced results. Figure 1 is an architecture diagram showing conceptually how some of the OGC Web Services are related, and naming some (not all) of the operations they define.

WMS WFS

Openlayers

Many formats for Layers
OGC WMS Google Maps MSN Live Local Yahoo! Maps Multimap ka-Map WorldWind OGC WFS GeoRSS CSV GML KML WKT Vector Layers, points, lines, polygons rendered with SVG / VML 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. The WPS interface specifies three operations that can be requested by a client and performed by a WPS server, all mandatory implementation by all servers.

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. The WPS interface specifies three operations that can be requested by a client and performed by a WPS server, all mandatory implementation by all servers.

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 web-accessible resource.

WPS Interaction Diagram
Note in UML sequence and collaboration diagrams are often called interaction diagrams From ; OpenGIS® Web Processing Service (05-007r7_Web_Processing_Service_WPS_v1.0.0) The mandatory Execute operation allows WPS clients to run a specified process implemented by a server, using the input parameter values provided and returning the output values produced. Inputs can be included directly in the Execute request, or reference web accessible resources. The outputs can be returned in the form of an XML response document, either embedded within the response document or stored as web accessible resources. If the outputs are stored, the Execute response shall consist of a XML document that includes a URL for each stored output, which the client can use to retrieve those outputs. Alternatively, for a single output, the server can be directed to return that output in its raw form without being wrapped in an XML response document. Normally, the response document is returned only after process execution is completed. However, a client can instruct the server to return the Execute response document immediately following acceptance by the server of the Execute request. In this case, the Execute response includes a URL from which the response document can later be retrieved during and after process execution. The server can be instructed to provide regular updates to a measure of the amount of processing remaining if the process is not complete. This allows the client to determine the process status by polling this URL. An example of how this works is shown in the8 **UML activity diagram** shown in Figure above.

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

Semantic interoperability of distributed geo-services by Rob Lemmens
For demonstration purposes a simple service chain has been created as a sequence of four services (see Figures 6.1 and 6.2). The aim of this service chain is to generate a map with information about potentially hazardous objects such as ammonia and fireworks depots, centred around a location provided by an end user. Each service in the chain is described by one operation with the same name as the service. The first part of the chain is implemented by the Alexandria Library Gazetteer service [115], which returns the coordinates of a point, based on an input location name. The second service (BBoxCreate) creates a bounding box around this point and a third (MakeGetMapRequest) creates a URL that contains the necessary parameters for the fourth service, an OGC-compliant Web Map Server, implemented with the University of Minnesota WMS software. Note that the result in Figure 6.2 is shown in a web browser, which acts as a client application. This client application is not part of the service chain itself. More on the creation of this chain can be found in [165].

Semantic interoperability of distributed geo-services by Rob Lemmens

Description Logics Two basic knowledge representation approaches,
logic-based formalisms and 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). Semantic interoperability of distributed geo-services by Rob Lemmens

Example Ontology Semantic interoperability of distributed geo-services by Rob Lemmens

Spatial Databases: Lecture 6

Similar presentations

Presentation on theme: "Spatial Databases: Lecture 6"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Spatial Databases: Lecture 6

Similar presentations

Presentation on theme: "Spatial Databases: Lecture 6"— Presentation transcript:

Similar presentations

About project

Feedback