5 CANRI from a Technical Perspective

Okay, this is where the talk gets a bit more technical. You should be familiar with basic GIS and internet terms terms and abbreviations. Refer to the Glossary if you're not sure about a TLA!

This section covers the CANRI framework in an abstract design sense, which may be particularly useful for Data Custodians, Web Application Managers and IT Support Staff.

5.1 Framework architecture

CANRI implements a typical 3-tier architecture. To make sure we understand how this term is used in CANRI, let's take a quick look at each tier before moving into the details.

Applications

This is a troublesome term because it is so useful. Almost anything with a couple of moving parts can be called an application. In the 3-tier architecture, we are usually referring to end-user interfaces (ie, web pages rendered in the user’s browser) and client-side applets as applications.

Middleware

This is generally the domain of things "server-side". For example, a web server's Java servlet running environment is an example of middleware. Many CANRI applications make use of middleware services, provided by such products as MapBroker, for server-side functionality to a range of client applications.

Data sources

This is the raw input side of things. Data sources can be almost anything that has a geospatial reference, including raster images, vector feature data, or spatially referenced text documents.

Also included in this tier are utility collections, like metadata thesauri, gazetteers and data model repositories.

Data sources are addressable through data servers, which are the active agents that interact with the resource collection (eg, through a JDBC connection to a geospatial database).

Advantages of the 3-tier architecture

This arrangement provides a high degree of flexibility in a distributed environment. By cleanly separating each layer, and providing well-known, public Application Programming Interfaces (APIs) for the transport, encoding, data modelling and request formats, many individual participants can contribute to the network without the overhead of negotiating these agreements on a case-by-case basis. This is one of CANRI's most powerful concepts.

5.2 Functional model

Another way to look at the CANRI framework, from a functional perspective, identifies five "ACORN" components:

5.3 OGC Architecture

The OGC also recommends the 3-tier approach. The OGC Web Services Architecture (OWS) clarifies how these perspectives combine to form the specific components in an OGC context.

The OWS includes three principal types of geo-referenced 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. Following 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.

5.4 CANRI deployment

CANRI components are deployed at various servers throughout the NRIMS community. Although DLWC has played a significant role in establishing first-generation services, other agencies and CANRI partners are also adding services and resources to the framework.

There is no practical limit to scaling or extending the architecture to take advantage of additional data resources, evolving middleware and extended applications. The components implemented or planned in the CANRI framework are shown in the figure below. In the following sections you'll find detailed reference summaries for these components.

5.5 Web Map Server

Overview

Map servers are designed to provide map images of access to geographic data collections. To work in the CANRI environment, these map servers must implement the OGC Web Map Service (WMS) standard, which requires the server to support three requests:

GetCapabilities: Obtains service-level metadata, which is a machine-readable (and human-readable) description of the WMS's information content and acceptable request parameters. The response to a GetCapabilities request is general information about the service itself and specific information about the available maps.

The Capabilities document is an XML configuration file that is provided to requesting agents (such as MapBroker). The most critical part of the WMS Capabilities XML is the Layers and Styles it defines. This file is required by the WMS specification and must conform to the OGC’s DTD.

GetMap: Obtains a map image whose geospatial and dimensional parameters are well-defined per the WMS syntax specifications. The GetMap operation is designed to produce a map, which is defined to be either a pictorial image or a set of graphical elements. This a required function for WMS connectors.

Obtains a map image whose geospatial and dimensional parameters are well-defined as per the WMS syntax specifications. The GetMap operation produces a map, defined as either a pictorial image or a set of graphical elements. This is a required function for WMS servers.

It may surprise GIS experts to discover how simple the GetMap-supported parameters are. Remember, online mapping is very much in its infancy: making the most out of this first generation of specifications will build demand for more advanced capabilities.

Request Parameter	Required/ Optional	Description
VERSION=version	R	Request version.
REQUEST=GetMap	R	Request name.
LAYERS=layer_list	R	Comma-separated list of one or more map layers. Optional if SLD parameter is present.
STYLES=style_list	R	Comma-separated list of one rendering style per requested layer. Optional if SLD parameter is present.
SRS=namespace:identifier	R	Spatial Reference System.
BBOX=xmin,ymin,xmax,ymax	R	Bounding box corners (lower left, upper right) in SRS units.
WIDTH=output_width	R	Width in pixels of map picture.
HEIGHT=output_height	R	Height in pixels of map picture.
FORMAT=output_format	R	Output format of map.
TRANSPARENT=TRUE\|FALSE	O	Background transparency of map (default=FALSE).
BGCOLOR=color_value	O	Hexadecimal red-green-blue color value for the background color (default=0xFFFFFF).
EXCEPTIONS=exception_format	O	The format in which exceptions are to be reported by the WMS (default=SE_XML).
TIME=time	O	Time value of layer desired.
ELEVATION=elevation	O	Elevation of layer desired.
Other sample dimension(s)	O	Value of other dimensions as appropriate.
Vendor-specific parameters	O	Optional experimental parameters.
The following parameters are used only with Web Map Services that support the Styled Layer Descriptor specification
SLD=styled_layer_descriptor_URL	O	URL of Styled Layer Descriptor (as defined in SLD Specification).
WFS=web_feature_service_URL	O	URL of Web Feature Service providing features to be symbolized using SLD.

Note: Previously, the GetMap request was capable of returning Feature data. That is now the role of an OpenGIS Web Feature Service.

GetFeatureInfo: Asks for information about particular features shown on a map. The GetFeatureInfo operation is designed to provide clients of a WMS with information about a feature in a map image returned by a previous GetMap request.

The use case for GetFeatureInfo is that a user sees the response of a GetMap request and chooses a point on that map for which to obtain more information. The basic operation provides the ability for a client to specify which pixel is being asked about, which layer(s) should be investigated, and what format the information should be returned in. The actual semantics of how a WMS decides what to return more information about, or what exactly to return is left up to the WMS provider.

Within CANRI, this GetFeatureInfo capability has been exploited to provide a range of useful applications that access non-image data sources. Please note that this is properly the domain of a Web Feature Server, despite the rather confusing use of the terms within CANRI to date.

Note also that GetFeatureInfo is an optional capability for a WMS: software developers are not required to support it. This is another good reason to move toward the emerging WFS specification if you're primarily serving data and providing data interaction.

5.6 Web Feature Server

Overview

Feature servers are designed to provide access to (and interaction with) non-image data collections. Generally, WFS operations support INSERT, UPDATE, DELETE, QUERY and DISCOVERY of geographic features.

At the time of writing no implementation specification had yet been released for WFS, but we have a good idea of what it will look like. CANRI sponsored participation in the development of this spec through the OWS Testbed process, which has produced very useful advances in defining the access, interaction, and symbolisation parameters for time-series and sensor data collections.

It is expected that a basic WFS server will support three requests: GetCapabilities, DescribeFeatureType and GetFeature. An advanced (transactional) WFS would additionally implement a Transaction operation, and LockFeature.

5.7 Gazetteer

Overview

Gazetteers are a specific type of web-based feature servers. Typically they are used to server controlled values, eg. geographic placenames.

In this context, a gazetteer provides a means to specify a geographic object through use of well known (common) names, such as a town name. Gazetteers are needed to navigate quickly and efficiently to targeted information or services available in CANRI. Without them, CANRI applications would be too difficult to navigate through or cross-link from other contexts. A placename gazetteer is also useful as an authoritative reference for spelling.

At present, local gazetteer copies (ie “non-authoritative” data) are served and used in production CANRI applications in the interim for high priority feature types such as catchments and LGAs. Authoritative third party services will be provided when available.

CANRI will be developing user interfaces for gazetteer functions as these are not yet well-evolved or standardised.

5.8 CANRI Catalog

Overview

The CANRI Catalog is network-addressable data server sitting on top of the NRDD and including service/availability details for data layers.

Catalogs are one of the most complex areas for CANRI, with issues including authority, how things are classified, completeness and duplication across multiple catalogs. Technical and policy standards are still at an early stage of development and are still evolving in different communities, such as libraries and GIS.

Recognising this difficulty, CANRI will be piloting the integration into CANRI web applications of access to a single high-priority non-CANRI spatial data collection: the Australian Natural Resources Data Library (ANRDL). The ANRDL is the repository for over 200 natural resources datasets created during the National Land and Water Resources Audit (NLWRA), and is managed by the Bureau of Rural Sciences (BRS) within the Commonwealth Department of Agriculture, Fisheries and Forestry (AFFA) [See the NLWRA website]

How the CANRI Catalog is used

The CANRI Catalog is available to framework applications as a CSGI dataserver. The CSGI protocol is a forerunner of current OpenGIS specifications.

Currently, the Catalog is available to those applications that are configured to handle CSGI. These include the main NRDD browsing application (the NRA), the Australian Coastal Atlas, and PartnerPlus. New applications are expected only to implement the OpenGIS Catalog specification, and CANRI will be upgraded soon, per the CANRI CataloguePlus Project 02.

5.9 Natural Resources Data Directory (NRDD)

Overview

The Natural Resources Data Directory (NRDD) is a register of around 5,000 natural resource datasets held mainly by New South Wales State and local government agencies. Its purpose is to make natural resources data widely accessible by providing a friendly interface. The term data has been interpreted as broadly as possible and includes not only data in digital form (including satellite imagery) but also material in hardcopy formats such as printed maps, reports and photographs.

The NRDD covers a wealth of information for topics as diverse as vegetation and wildlife, inland and coastal waters, land use, soils, mineral resources, energy, urban planning, infrastructure, air pollution and many more. Much of the information listed in the NRDD is now priceless because it can never be collected again. Unlike other information, natural resources information remains extremely valuable regardless of its age.

It includes data collected over long periods of time, such as the heights and flows of rivers in NSW dating back to the late 1880's, as well as up to the minute information collected as part of specific projects.

Registration of data products in the NRDD is free. CANRI encourages those agencies, organisations and industries holding natural resources information to list their data.

How the NRDD is used

A student of architecture recently used the NRDD to find out how best to locate and access information about the town of Tamworth in north-western New South Wales for a major design project. She wanted historical and cultural information on town planning and development, soil surveys, maps indicating soil types, land contours and any other relevant information. This was all available through the NRDD.

Application designers who wish to access the NRDD and CANRI service catalog directly from their own applications should review Application development: Roll-your-own.

5.10 Natural Resources Atlas (NRA)

Overview

The NRA helps users discover and access natural resources data layers covering a wide range of environmental themes such as wildlife, vegetation, geology, land, water, pollution and more. It provides the ability to search all the data layers in the NSW Natural Resources Data Directory (NRDD) and to view those which have been made available online.

The NRA enables users to select an area of interest on a map and search approximately 5,000 data records currently listed in the NRDD. Searches can be formulated on a particular theme, keyword, or physical property. The NRA functions as a catalog browsing tool for the NRDD.

Although technically speaking the NRA is just another CANRI application, it is included here as a core framework component due to its role as the primary access interface to the data served in the CANRI framework.

How the NRA is used

Let's say you wish to find and view what water and soil quality information exists near Wollongong. Zoom in on the map to Wollongong, using the zoom controls and pan to frame up your area of interest.

Then, from the legend option [Search for Data], use the pop-up search interface to locate suitable data layers. You could add data to the map such as Streamwatch sample points, groundwater availability or acid-sulfate soil risk assessments in the Illawarra. When you have selected all your data layers, choose to [Use these Layers] and you will be returned to the main NRA map interface with your map layers added.


Community Access to Natural Resources Information	...the power of shared information