The role of web services for spatial data delivery
Ed Parsons
Chief Technology Officer Ordnance Survey
Romsey Road SOUTHAMPTON SO16 4GU
E-Mail: eparsons@ordsvy.gov.uk
Abstract
The IT industry is currently calling Web Services the “next big thing” and it is clearly the
recipient of some considerable hype at this point in time, nevertheless the concept of
intelligent system to system communication may solve many of the problems of joining up
disparate geospatial data sets and services.
Web services are the building blocks of the future distributed computing platform on the
Internet. Open standards here are key, with a focus on communication and collaboration
among people and applications rather than strict descriptions of particular geographical data
models. This is possible through the use of XML schemas such as GML as the mechanism
for application integration.
This paper will investigate how through the use of Web Services and the technologies of
SOAP and UDDI organizations such as the National Mapping Agencies, Government
departments, Software Vendors and System integrators can interface their data and services
to provide seamless applications which leverage their combined offerings transparently to the
end user.
For example a future web services user may login to a building society branded website
which has an online housing buying assistant application. The application itself a web service
could communicate with other web services across the internet to identify if a potential
property, was a risk of flooding, had a registered title, could be connected to cable TV etc.
The user might also register to have mail redirected, utilities and services connected and the
electoral role updated. Each of the organization systems involved would remain dedicated to
that organisations operation but would present a web services compliant interface to the
others to allow meaningful collaboration.
Such integration and collaboration has often been promised in the past, but now finally we
have a technology which can begin to deliver joined up geography.
The problems in joining geographies
The power of geography as an integrating force is well recognised allowing disparate sets of
data to be brought together based upon a common location so that the underlying relationship
between for example poor health and industrial pollution can be identified. This can only take
place if both data sets have been collected on a common framework or geography which
allows their location to be identified, the use of coordinates such as the National Grid
reference or Latitude and longitude is the most common direct method. In most cases
however the location must be identified using another geography from which we can indirectly
imply a location, Postal addresses, UPRN, TOID, census output areas, and parliamentary
constituencies are all examples of these alternative geographies.
The geocoding process of obtaining a discrete location from these many geographies is
developing into quite a cottage industry with much effort been duplicated across the GI
industry in the UK to bring these datasets together. The conflagration process often involves
both an understanding of the underlying data structures and formats but also the application
of geographical information science in combining datasets with different temporal and spatial
resolutions.
The largest problem in joining geographies is however organisational, identifying who has
information, how the information was collected and how it is structured (metadata) and
actually getting access to the data itself on CD, Tape paper or even online !
To use an analogy to describe access of geographical information in the UK today, we are
currently experiencing the early days of the internet when to read an article or document on a
server on the internet, a user would need to know the IP address of the actual server, the
access protocol to download the document (who remembers gopher?) a binary
encoding/decoding application, the file format of the document and the appropriate file viewer.
Today of course we just point our browser at google.com, enter some relevant text as a
search string and view the pdf document! We are still someway of bringing that level of
integration to the proprietary and specialised realm of GI data but the technology of web
services appears to hold the key to this level of usage.
Web services defined
So far the internet and the World Wide Web developed on top of it, has been about the
dissemination of digital information from a server computer somewhere to a user using a
client computer somewhere else. The information is transported and presented in such a way
that a human is really required to interpreter the information. The technology behind Web
services removes the need for human interaction allowing different software applications to
communicate and share information is a well defined and structured way allowing processing
to take place as a “back office” activity. For this reason despite all the current hype
surrounding web services many uses of the internet or IT systems is general may not notice
the revolution taking place behind the scenes of their familiar application.
A more technical definition of a web service is a “URL-addressable software resource that
performs functions and provides answers” (Seybold, 2002). The Web Service is an
encapsulation of perhaps existing software functionality in a common form that allows the
services it performs to be visible and accessible to other software applications. A single web
services based application can request services from other Web Services, and can expect to
receive the results or responses from those requests in an expected form.
The great advantage over existing integration technologies is that Web Services are designed
to interoperate in a loosely-coupled manner; they can request a particular type of services
across the internet and wait for responses. A Web Service can be discovered and used by
other Web Services, applications, clients, or agents. Web Services may be combined or
chained to create new services. And they may be recombined, swapped or substituted, or
replaced at runtime.
To illustrate this, an organisation might require as part of their corporate portal a location map,
which could be delivered as a web services from a map publisher which in turn obtains the
raw spatial data from a street centreline database developer which in turn receives data from
a web service publishing data from the national mapping agency. Any one of these providers
could be changed to another in real time without any application development or change in
functionally. This change might occur because the data feed might be disrupted, or a “better”
supplier might be identified as the preferred choice.
