Spatial Information Services Stack
Web Feature Service &Web Map Service
(WxS)
Rini Angreani, Josh Vote, Ben Caradoc-Davies, Robert Woodcock
CSIRO Earth Science and Resource Engineering
Perth, Australia
Robert Atkinson
CSIRO Land and Water
Sydney, Australia
17 December 2010
Abstract
The Spatial Information Services Stack (SISS) is a project developed for the AuScope
Grid to provide a suite of tools that supports its infrastructure in achieving spatial data
interoperability. Web Feature Service (WFS) and Web Map Service (WMS) are the
essential components in SISS to help achieve this aim using a web interface. WFS and
WMS provide the modern alternatives to the conventional data sharing which can be a
difficult and slow process due to the difference in data format and platforms among
users. WFS lets users access data in a well defined base format instantly, which means
that it is platform independent, and can be extended or transformed into other formats
to suit their needs. WMS works as a visual tool to display spatial data as images.
Through WFS and WMS in SISS, users can view, access and analyse data from
multiple sources using a single client interface.
Keywords: WFS, WMS, WxS, Web Feature Service, Web Map Service, Complex
Features, GeoServer, Application Schema, app-schema
1. Introduction
The Open Geospatial Consortium (OGC) defines standards for spatially enabled web
applications. This document will discuss the use of OGC Web Feature Service (WFS)
[1] and Web Map Service (WMS) [2] in the Spatial Information Services Stack
(SISS). Both WFS and WMS serve the purpose of interoperability by publishing
spatial data. WFS is used to query data which may contain spatial information,
whereas WMS is used to retrieve map images. When used together, WFS and WMS
complement each other where WFS provides access to the underlying detailed
information behind the simplified map imagery generated by WMS.
2. WFS/WMS in SISS
The SISS project is initially developed as part of the AuScope Grid [3] to provide a
suite of tools in achieving spatial data interoperability within the geoscience
community. However, it is applicable to any other fields with spatially located
information, including those as diverse as meteorology, water resources, fisheries, and
health. Interoperability is crucial as the geoscience community relies on data from
other providers to help analyse their own. The conventional way of sharing data is not
an easy process, as there are no standards across data providers on the storage type
and format. In order for users to view data from a specific provider, they often have to
convert the data before importing to their own database.
This process is even more time consuming when dealing with multiple data providers
with varied backends. WFS eases interoperability by enabling queries on data from
multiple providers, regardless of their backend type. The data is returned as XML,
which is a standardised, extensible format that is also platform independent and
recognised internationally. Furthermore, the data is provided almost instantly after
executing the query, ensuring that they are up-to-date.
WMS provides data in the form of map images and is primarily used as a visualisation
tool within SISS. Similar to WFS, it increases interoperability by easing sharing data
without the need for data conversion. Users can specify a certain image format when
making a query. It is also possible to create a single client interface to access multiple
WFS and WMS instances from multiple sources, as demonstrated in the AuScope
Discovery Portal [4].
3. GeoServer
There are a number of technologies that serve WFS and WMS, both commercial and
open source. The SISS project aims to provide a low-barrier to entry, therefore open
source software suits this goal better since it is typically free or low-cost and has less
restrictive licensing. Open source projects also normally accept external contribution,
allowing collaborators to tailor them with our specific requirements. SISS provides
support for multiple WFS/WMS implementations, however GeoServer [5] was chosen
as the default implementation because it has a wider community, providing more
support and chances for collaboration. GeoServer is also renowned for being Certified
OGC Compliant for its implementations of WMS 1.1.1 [2] and is the reference
implementation of WFS 1.0.0 [6] and WFS 1.1.0 [1]. In this document, all references
to default WFS/WMS implementation in SISS refer to GeoServer, unless stated
otherwise.
A notable competitor to GeoServer is deegree [7] which is also an open source project
that is OGC compliant and supported as an alternative within SISS. However, deegree
has a smaller community which makes support and maintenance more difficult.
Furthermore, in the beginning of the SISS project, deegree version 2.x requires XSLT
in order to use it for serving complex features, which makes user configuration
difficult. Snowflake Software [8] also provides an OGC compliant solution but it does
not have the open source advantage.
3.1 Platforms Supported
GeoServer is written in Java which is platform independent, so can be run on
Windows, Linux and Mac operating systems. SISS developers have been using both
Windows and Linux to run GeoServer. GeoServer is a Java servlet and is deployed in
a servlet container such as Tomcat or Jetty
3.2 Data Stores
GeoServer supports a wide range of data sources in many forms. It supports databases
such as DB2, MySQL, SQL Server, Oracle, PostGIS, ArcSDE and many others. It
also allows users to configure shape files or a directory as a data source, consuming
another WFS output as a data source, and others. There are limited amount of
supports for certain data stores, however this is improving. The GeoServer User
Manual [9] provides more details on using data stores.
4. WFS
‘The 'Feature' is the fundamental unit of geospatial information’ [10]. Web Feature
Service is an XML web service that enables users to retrieve features from distributed
data sources using queries against spatial and non-spatial properties. WFS-T
(Transactional) [6] also allows editing features, i.e. inserting, updating and deleting
the data but it is outside the context of this project and will not be discussed here. The
OGC defines levels of feature compliance: SF-0 and SF-1 [11], which correspond to
what we refer to as simple and complex features in GeoServer. GeoServer has
implemented WFS 1.0.0 and 1.1.0 with reference to OGC standards. In SISS,
GeoServer is used with WFS 1.1.0.
4.1 Simple Features
A simple feature in GeoServer is at an OGC SF-0 compliance level. The features can
only have spatial properties and restricted built-in non-spatial properties of the
following types: string, integer, measurement, date, real, binary, boolean and URI.
Each property is also limited to 0 or 1 value, not allowing for “multi-valued”
properties [11].
Simple features are mapped automatically in GeoServer, with every table as a feature
type, and every column as a property type. The GeoServer GUI makes configuring
simple features to data sources even easier. Schemas are not required to govern the
output format, as they are produced based on the database structure. Consumers can
access the schemas via a specific WFS request called DescribeFeatureType, which is
discussed further in section 4.4.3.
For example, Table 1 shows a database table called “offices” containing information
about office locations.
id
PER
state
WA
Suburb
Perth
location
POINT(115.858591, -31.955101)
KEN
SUB
WA
WA
Kensington
Subiaco
POINT(115.883181, -31.986774)
POINT(115.823915, -31.948619)
Table 1. Example of a database table "offices".
GeoServer would produce the simple features as shown in Figure 1 following a
getFeature request.
<offices gml:id="PER">
<state>WA</state >
<suburb>Perth</suburb >
<location>
<gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326">
<gml:pos>-31.955101 115.858591</gml:pos>
</gml:Point>
</location>
</offices>
<offices gml:id="KEN">
<state>WA</state >
<suburb>Kensington</suburb >
<location>
<gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326">
<gml:pos>-31.986774 115.883181</gml:pos>
</gml:Point>
</location>
</offices>
<offices gml:id="SUB">
<state>WA</state >
<suburb>Subiaco</suburb >
<location>
<gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326">
<gml:pos>-31.948619 115.823915</gml:pos>
</gml:Point>
</location>
</offices>
Figure 1. The getFeature result on data from Table 1.
With the straightforward mapping mechanism, GeoServer streams simple features
from the data source with a high performance. However, the ease of configuration and
high performance also comes with disadvantages. Since the schema is based on the
database structure, other data sources also have to adapt the same structure to serve
features of the same types. This limits interoperability for multiple users who want to
share the same feature types. Additionally, some features have “multi-valued”
properties, which cannot be expressed with simple features. Most significantly, a
simple feature cannot contain deeply structured information, such as another feature,
limiting its ability to represent relationships between different feature types.
4.2 Complex Features
As previously discussed, simple features have limitations in serving certain data
structures. Complex features adapt OGC feature compliance level SF-1 to overcome
these limitations.
4.2.1 Advantages
The advantages of complex features are detailed in sections 4.2.1.1 to 4.2.1.3.
4.2.1.1 Rich Data Representations
SF-1 compliant features can have “multi-valued” properties, and user defined
properties. Features can also contain rich, complex data that cannot be served as
simple features. For example, referring to the “offices” example in section 4.1, we can
extend the features to include information about the employees, which have their own
data. The feature that we want to achieve would be shown in Figure 2.
<offices gml:id="PER">
<state>WA</state >
<suburb>Perth</suburb >
<location>
<gml:Point srsName="urn:x-ogc:def:crs:EPSG:4326">
<gml:pos>-31.955101 115.858591</gml:pos>
</gml:Point>
</location>
<employees>
<employee gml:id=”rangreani”>
<name>Rini Angreani</name>
<role>Software Engineer</role>
</employee>
<employee gml:id=”jsmith1”>
<name>John Smith</name>
<role>Tester</role>
</employee>
</employees>
</offices>
Figure 2. An example of a complex feature.
The above example has “multi-valued” properties, which are quite common in many
real life datasets. Moreover, relying on the database schema is not possible for this
example, as it would not be able to map nested attributes, i.e. the properties of
“employee” straight from the database. This is where user defined properties in
complex features are useful. The properties are defined in separate target schemas that
are often community agreed and maintained. Users have to map the properties from
the schemas to relevant fields in the database via an XML mapping file for each
feature type. This is illustrated in Figure 3.
Figure 3. How complex features are produced [12].
4.2.1.2 Data Source Flexibility
Complex features in GeoServer can be configured from multiple tables per feature,
giving more flexibility in the database design. Simple features require a single table to
represent one feature type; each table can get very large and difficult to manage when
many properties are present. It also means that users have to ensure they have the
same table structures in order to publish the features of the same feature type.
However, complex features of the same type can be published from different data
sources of different structures. This increases interoperability since users would be
able to readily share their data without having to modify their table structures.
4.2.1.3 Polymorphism
Some data has conditional output that can have the form of different structures, to be
determined at run time. This is what we call polymorphism in complex features. The
most common scenario is when an attribute has a certain column value that mandates
an attribute to be encoded with a certain structure. Complex features can be mapped
with the conditions that are evaluated as the features are constructed. For example, the
attribute er:material in EarthResourceML schema can be encoded as
gsml:RockMaterial or gsml:Mineral, depending on the value of a column that stores
the material type.
The mapping for the attribute can contain a function as shown in Figure 4.
<AttributeMapping>
<targetAttribute>er:material</targetAttribute>
<sourceExpression>
<linkElement>if_then_else(equalTo(MATERIAL, ’rock’),
’gsml:RockMaterial’, ’gsml:Mineral’)
</linkElement>
</sourceExpression>
</AttributeMapping>
Figure 4. An example of conditional attribute mapping.
The function translates to mapping er:material as gsml:RockMaterial type if the value
of MATERIAL column is equal to “rock”, otherwise encode it as gsml:Mineral type.
4.2.2 Application Schema
Complex features in GeoServer are handled by the application schema support [13]
plugin, often referred to as “app-schema”. The application schema support plugin uses
the existing architecture of simple features and builds complex features out of the
simple features as illustrated in Figure 5.
Figure 5. A diagram illustrating how application schema works.
App-schema allows data from multiple tables to be compounded into a single
complex feature type. This mechanism is called feature chaining. To configure the
“offices” example mentioned before, we can use feature chaining to map employee
data from “employees” table into the “offices” configuration. The XML mapping file
would look like similar to that shown in Figure 6.
<FeatureTypeMapping>
<sourceDataStore>myDatabase</sourceDataStore>
<sourceType>offices</sourceType>
<targetElement>offices</targetElement>
<attributeMappings>
<AttributeMapping>
<targetAttribute>state</targetAttribute>
<sourceExpression><OCQL>STATE</OCQL></sourceExpression>
</AttributeMapping>
<AttributeMapping>
<targetAttribute>suburb</targetAttribute>
<sourceExpression><OCQL>SUBURB</OCQL></sourceExpression>
</AttributeMapping>
<AttributeMapping>
<targetAttribute>location</targetAttribute>
<sourceExpression><OCQL>LOC</OCQL></sourceExpression>
</AttributeMapping>
<AttributeMapping>
<targetAttribute>employees</targetAttribute>
<sourceExpression>
<OCQL>EMPLOYEE_IDS</OCQL>
<linkElement>employees</linkElement>
<linkField>FEATURE_LINK</linkField>
</sourceExpression>
</AttributeMapping>
</attributeMappings>
<FeatureTypeMapping>
<FeatureTypeMapping>
<sourceDataStore>myDatabase</sourceDataStore>
<sourceType>employees</sourceType>
<targetElement>employees</targetElement>
<attributeMappings>
<AttributeMapping>
<targetAttribute>FEATURE_LINK</targetAttribute>
<sourceExpression><OCQL>getID()</OCQL></sourceExpression>
</AttributeMapping>
<AttributeMapping>
<targetAttribute>name</targetAttribute>
<sourceExpression><OCQL>NAME</OCQL></sourceExpression>
</AttributeMapping>
<AttributeMapping>
<targetAttribute>role</targetAttribute>
<sourceExpression><OCQL>ROLE</OCQL></sourceExpression>
</AttributeMapping>
</attributeMappings>
<FeatureTypeMapping>
Figure 6. Sample mapping file that uses feature chaining.
The mapping file gives us the flexibility to map any database fields to attributes from
the target schemas. The output is validated against the schema, but the validation is
not so restrictive that it still leaves some flexibility for the users. For example, if the
user configures attributes that don’t exist in the provided schemas, they would be
ignored and won’t be encoded in the output. However, if the user misses some
mandatory fields in the mapping file, the output will be encoded as configured
without any warning to the user. It is assumed that it is the user’s responsibility to
ensure the output conforms to the target schemas. Third party XML editors like
XMLSpy [14] can be used to validate the output.
As the Graphical User Interface (GUI) does not cater for configuring complex
features, the mapping file has to be written manually. Manual editing makes it more
error prone, as users would often make syntax mistakes and don’t realise it. It is
therefore crucial to have meaningful error messages in relation to mapping syntax,
and this process has been improving since the beginning of the implementation.
4.3 Why Use WFS
WFS produces spatial data in XML form, which can be shared and consumed for
various purposes. The following sections discuss the advantages of using WFS in
more details.
4.3.1 Interoperability
As WFS allows retrieving features from multiple data sources of different types, it
increases interoperability between multiple data providers. Conventionally, users had
to make a back up of their database and send it to other users. The multi-step process
may mean that the data is no longer relevant or has changed upon receipt. Even
worse, if their platforms or database types differ with each other, they have to convert
the database in order to use it. Users can configure WFS to publish their data
conveniently and ensure the information they’re sharing is up-to-date with the
database. With WFS-T, real-time editing of the data can also be performed, as it
allows users to update or delete features. However, this is not yet available for
complex features and is considered as part of future works.
WFS data is returned in XML format, which is a common syntax used in exchanging
information. Since XML is a well known extensible format, a lot of applications can
readily consume the data, and tailor them to their requirements. Interoperability is
enhanced even further by using a community-agreed GML application schema, which
defines in detail the meaning of each part of the data. The data can be downloaded to
be analysed, and edited easily with consistent format, or transformed into different
forms. A common example is to use a third party application to consume the data and
visualise them. The features with spatial information are normally displayed as place
marks on a map that also displays additional information. Figure 7 shows an example
of a visualised simple feature with flat data.
Figure 7. A visualised simple feature with flat data [4].
In AuScope Discovery Portal , complex features are visualised with links to related
features. For example, the feature in Figure 8 displays a link to “Commodity
Description”. When the link is clicked, it will display a window with the linked
information as shown in Figure 9.
Figure 8. A visualised complex feature with a link to nested data [4].
Figure 9. A window displaying linked information [4].
4.3.2 Filter Support
WFS also allows users to retrieve a selective subset of data to ease analysing relevant
data only. Filtering speeds up the process of getting the desired data without having to
manually parse the full output, which can be very large. For example, a geologist can
query geologic features that contain certain composition that he/she is interested in.
There are many types of filters to consider, and they can be combined to numerous
possibilities. The great advantage of complex features is that they can represent
relationships between features, and allow WFS filter queries to select features based
on their relationships. For example it is possible to ask the following of such services,
“show me all the mines within this region of Australia that have known reserves of
gold”.
4.3.3 Spatial support
In the case where spatial data is concerned, WFS will serve the data with the provided
Coordinate Reference System (CRS). CRS determines the location and dimension of
the geometries contained in the features, with reference to the Earth. Spatial data are
normally provided with relevant CRS in the database, or that default CRS is set within
the configuration. Users are able to reproject the features, translating the data from its
set CRS code to another CRS code. Reprojecting can be done by setting a CRS in the
WFS request parameter. This support is crucial because different CRS codes are used
across the world, and the interpretation of geospatial data would vary accordingly.
For example, a feature that has a native CRS of EPSG:4326 may have a geometric
attribute as shown in Figure 10.
<gsml:shape>
<gml:Point srsDimension="2" srsName="urn:xogc:def:crs:EPSG:4326">
<gml:pos>-28.564421 122.480003</gml:pos>
</gml:Point>
</gsml:shape>
Figure 10. Sample feature with EPSG:4326 projection.
Appending “&srsName=urn:x-ogc:def:crs:EPSG:4238” in the request would produce
the feature with reprojected values as shown in Figure 11.
<gsml:shape>
<gml:Point srsDimension="2" srsName="urn:xogc:def:crs:EPSG:4238">
<gml:pos>-28.564428478730168 122.47972006450976</gml:pos>
</gml:Point>
</gsml:shape>
Figure 11. Sample feature reprojected to EPSG:4238.
WFS also enables users to filter data that satisfy specific bounding box constraints.
This is useful for getting features that are relevant to specific area only. Figure 12
illustrates an example of a visualised result of WFS GetFeature request with bounding
box query.
Figure 12. Visualised results of WFS bounding box query [4].
It should be noted that spatial support for WFS in GeoServer is limited to two
dimensional (2D) data at the time of writing.
4.3.4 Standards
WFS, WMS and their dependencies are OGC standards that are publicly available.
These standards and specifications ease implementations and usage of the service,
since users and developers can refer to the same documents for consistency.
4.4 How to Use WFS
This section will summarise the main types of WFS requests used in SISS. Please
refer to the WFS OGC specification [1] document to see all types of requests and how
to use them.
4.4.1 GetFeature
The GetFeature request is used to retrieve features, often garnished with filters. When
a GetFeature request is executed, GeoServer retrieves relevant data from the data
sources, builds the features and returns them in XML form. Filters can be specified to
restrict spatial or non-spatial attributes, or a combination of them. Often maxFeatures
is specified to get a certain number of features in shorter time, instead of getting the
full amount of features.
4.4.2 GetCapabilities
This request is used to describe the deployed WFS capabilities, i.e. all the available
feature types and their respective supported operations and filters. For example, the
extract of a GetCapabilities request in Figure 13 shows that queries can be run against
the “gsml:Borehole” feature type.
<FeatureTypeList>
<Operations>
<Operation>Query</Operation>
</Operations>
<FeatureType>
<Name>gsml:Borehole</Name>
<Title>Borehole</Title>
<Abstract>Borehole Collar Location</Abstract>
<DefaultSRS>urn:x-ogc:def:crs:EPSG:4326</DefaultSRS>
<ows:WGS84BoundingBox>
<ows:LowerCorner>-180.0 -90.0</ows:LowerCorner>
<ows:UpperCorner>180.0 90.0</ows:UpperCorner>
</ows:WGS84BoundingBox>
</FeatureType>
</FeatureTypeList>
Figure 13. Sample of getCapabilities result.
4.4.3 DescribeFeatureType
DescribeFeatureType is used to retrieve the schemas that define a feature type that is
available in the service. The schemas are useful for end users for reference to the
possible output so they can validate the features against them, or construct a mapping
file for complex features. As GeoServer automatically maps database fields for simple
features, the output of this request reflects the structure of the database table
concerning the feature type. However, app-schema users must define the locations of
the target schemas, in their mapping file. The target schemas in complex features can
be multiple, but most of the time only the top level schema is required, as the schemas
are often related and GeoServer recognises imports and includes within schemas. As a
result, DescribeFeatureType on complex feature types would produce the provided
locations of the target schemas.
4.5 Future Work
GeoServer does not serve complex features as fast it does for simple features. Reusing
simple features streaming mechanism for complex features is not suitable when
multiple tables are involved. The need to amend the underlying architecture to
improve feature chaining performance has been identified for future work. The
current workaround to improve performance is to use materialised database views as
opposed to regular database views.
With the lack of GUI to configure complex features in GeoServer, good configuration
error reporting is essential to aid the process; this (at time of writing) is work in
progress. However, once the GUI has been implemented, this will become less
critical. Having a GUI for app-schema would save a lot of time in learning the
configuration file syntax and the manual efforts to construct the mapping files.
Standards keep changing as new requirements and improvements are identified. It is
important to conform to the most recent standards, and be aware of the upcoming
changes. Support for GML 3.2 is currently being implemented in GeoServer and will
be available soon. Interests in using WFS 2.0 have also been expressed by many
parties, and there are plans to add this support in GeoServer. Catering for 3D spatial
support is also an important candidate for future work.
Last but not least, letting users edit complex features in real time would be a good
feature. That is, extending WFS-T for app-schema to allow executing transactional
operations on complex features.
5. WMS
A Web Map Service (WMS) is a web service that implements the OGC WMS
standard. GeoServer has implemented WMS 1.1.1 which is the chosen reference for
this project. Simple visualisations are a powerful tool, and for some use-cases they
can be just as important as access to the scientific data. WMS provides limited access
to the underlying data and so its main strength is in its simplicity of use. A user can
request, reproject and redesign visualisations of data, which are computed on the
service, without the need to transfer the raw data back to the client. As such it is
primarily used as a visualisation tool within SISS.
5.1 Why Use WMS
WMS is a dataset visualisation tool, it can be used for a variety of use-cases which
include:
 Dataset discovery - Being able to visualise all data for a specific spatial region
can aid in finding potential datasets to incorporate into a model.
 Quality control - Being able to visually reference aspects of data against
specific landmarks or other spatially referenced datasets to ensure they
conform to expectations.

Visual correlation - Being able to visualise multiple datasets that exist in a
similar area may help to identify possible correlations and interactions
between the datasets.
Being a visualisation tool, WMS is best used as part of a graphical user interface in
conjunction with a software package or library that supports it.
5.2 How to Use WMS
This section summarises the main types of WMS requests used in SISS. Please refer
to the WMS OGC Specification [2] document to see all the types of requests and how
to use them.
5.2.1 GetCapabilities
This is the first request to be made when accessing a WMS; the response will contain
general information about the service along with a list of layers. Each layer within a
WMS represents a distinct data source that can be queried using the various WMS
requests described in this section. The GetCapabilities request can also be used to
extract provider information, available raster formats and supported spatial reference
systems.
5.2.2 GetMap
The GetMap request allows users to request a layer as a raster image. It can accept
parameters to spatially subset a layer and reproject it to a known spatial reference
system. A typical request consists of a layer name, bounding box (in a supported
spatial reference system) and desired output dimensions.
The responses from a GetMap request in Figure 14 and Figure 15 are for the same
layer but with different request parameters.
Figure 14. A WMS response using EPSG:4326 and no bounding box [15].
Figure 15. A WMS response using EPSG:4326 longitude 110 to 129 and latitude -13 to -36 [15].
5.2.3 GetFeatureInfo
GetFeatureInfo is an optional operation that allows the client to request the underlying
data from certain locations on the map [2].
To make a GetFeatureInfo request you must specify a layer and a spatial location in the query.
The response will typically be a raw XML description of the data at that location; some services
also support requesting the data as a HTML page that can be displayed in a web browser as in
Figure 16.
Figure 16. The HTML results of a GetFeatureInfo request from Southern Queensland [15].
5.2.4 GetLegendGraphic
GetLegendGraphic is another optional operation that when implemented returns a
raster image Figure 17 that will represent the legend or key of a particular layer. A
legend will assign a distinct meaning to any ambiguous aspects of a GetMap request.
Figure 17. The results of a GetLegendGraphic request [15].
5.3 Current Use
WMS has been utilised in various places within the AuScope Discovery Portal which
allows many instances and layers to be composed and viewed simultaneously. Figure
18 shows two layers from two separate WMS instances being overlaid on a map of
South Australia.
Figure 18. Geologic age [15] and seismic station locations overlaid on South Australia through
the AuScope Discovery Portal.
5.4 Future Work
Although the GeoServer SISS component supports generating a WMS for the
previously defined SF-0 features, there is currently no WMS support for SF-1
features. What this means is that although data is now accessible through SF-1
features, there is no easy way to visualise this data. Every dataset must have a domain
specific visualisation solution instead of a general purpose WMS.
Future work could involve more GeoServer application schema development to
extend WMS support to complex features.
Being a visualisation tool WMS is typically used in conjunction with other standards
for accessing data. The WMS 1.1.1 standard doesn’t include any provisions for
referencing any related services and as a result any such references have to be
maintained manually. There is an opportunity here for an extension to the standard
that could allow a WMS to specify that the underlying data is also accessible via WFS
or otherwise.
6. Conclusion
Both Web Feature Service and Web Map Service are important components in SISS,
as they assist in achieving spatial data interoperability by allowing easy access to data
from multiple data sources. WMS allows displaying map images, whereas WFS
provides more complex operations, suitable for analysing spatial data. Some data can
be very rich and is best represented as complex features, using the application schema
extension in GeoServer. The main functionality of application schema extension is to
enable complex queries of data in an interoperable format. It is an ideal tool in
achieving spatial data interoperability. The capability of the application schema
extension will further improve as work is being conducted to enhance performance
and enable displaying map images extracted from complex features. The addition of a
graphical user interface to ease configuration would make it even more attractive.
REFERENCES
[1] OpenGIS Web Feature Service (WFS) Implementation Specification, OGC 04094, 2005. Available: http://www.opengeospatial.org/standards/wfs
[2] OpenGIS Web Map Service (WMS) Implementation Specification version 1.1.1,
OGC 01-068r3, 2002. Available: http://www.opengeospatial.org/standards/wms
[3] AuScope Grid. Available: http://www.auscope.org.au/content.php/content/id/12
[4] AuScope Discovery Portal. Available: http://portal.auscope.org/
[5] GeoServer. Available: http://geoserver.org/display/GEOS/Welcome
[6] Web Feature Service Implementation Specification, OGC 02-058, 2002.
Available: http://www.opengeospatial.org/standards/wfs
[7] deegree. Available: http://www.deegree.org
[8] Snowflake Software. Available: http://www.snowflakesoftware.com
[9] “Working with Data”, GeoServer User Manual, viewed 08 October 2010.
Available: http://docs.geoserver.org/stable/en/user/data/index.html
[10] S. Cox, “Feature Model and Encoding”, Solid Earth and Environment GRID,
viewed 08 October 2010. Available:
https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/FeatureModel
[11] Geography Markup Language (GML) simple features profile (1.0.0), OGC 06049r1, 2006. Available: http://www.opengeospatial.org/standards/gml
[12] G. Roldan 2005, viewed 08 October 2010. Available:
http://svn.osgeo.org/geotools/trunk/modules/unsupported/app-schema/appschema/src/main/java/org/geotools/data/complex/doc-files/complexdsscheme.png
[13] B. Caradoc-Davies & R. Angreani 2009, “Application Schema Support”,
Geoserver User Manual, viewed 08 October 2010. Available:
http://docs.geoserver.org/latest/en/user/data/app-schema/index.html
[14] Altova XMLSpy. Available: http://www.altova.com/xmlspy.html
[15] Geoscience Australia WMS, “AUS GA 1:2.5M Geologic Unit – Age”, viewed 08
October 2010. Available: http://www.ga.gov.au/map/broker/wms_info.php