Table Joining Service (TJS)

Overview

The Table Joining Service (TJS) defines a simple way to describe and exchange tabular data that contains information about geographic objects. TJS takes attribute data (which refers to spatial features, or “geolinked data”) and joins it to a geospatial dataset so that it can be mapped by a Web Map Service (WMS) or used in a Geographic Information System (GIS). It serves as a front-end to an existing WMS, and enables real-time mapping of data stored in non-spatial databases.

The TJS takes the attributes found in a set of geolinked data and merges them with a related set of geospatial data to produce a combined set of geospatial data which contains those attributes. The merging of these datasets is based on the use of a linkage field that is common to both sets of data (key field). The TJS can be used to publish information via an existing Web Map Service (WMS). The related set of geospatial data may reside locally, or it can be provided by a Web Feature Service(WFS).

Almost all corporate databases contain some kind of geographic identifier, regardless of whether or not the database is housed in a computing environment that supports a GIS. Geographic identifiers can include postal codes, municipality names, telephone area codes, or more special-purpose identifiers such as school districts. Geospatial linking technology allows this corporate data to be found and used for mapping or spatial analysis.

Additional Information

Standard

OpenGIS® Georeferenced Table Joining Service Implementation Standard

Related Information

Web Map Service (WMS)

Web Feature Service(WFS)

Web Processing Service (WPS)

Notes

Based on initial work undertaken in support of the Canadian Geospatial Data Infrastructure (CGDI), The TJS Standard has been published by the Open Geospatial Consortium (OGC).

Additional Information: Table Joining Service (TJS)

Development of the TJS Standard

Joining Attribute Data with a Geographic Framework

Optimizing Data Management

Additional Information Resources

Development of the TJS Standard

This standard is the result of work undertaken initially to support the CGDI, and in particular the Canadian Soil Information System (CanSIS) and the National Forest Information Service (NFIS). The standard was implemented as a prototype in 2002 by Agriculture and Agri-Food Canada (AAFC). In 2004 the OGC® issued a set of two discussion documents (04-010: Geolinked Data Access Service (GDAS), and 04-011: Geolinking Service (GS)).

The concept and associated interfaces were further refined, resulting in a number of recommended improvements to the standards including that they be merged into a single standard, published as Geographic Linkage Service (GLS) in 2008, with an OGC Request for Comments.

The current version, Table Joining Service (TJS), incorporates additional recommendations received and replaces all earlier documents.

To illustrate the evolution of the documents:

Joining Attribute Data with a Geographic Framework

TJS specifies how to perform a table join for spatial data, where attributes housed on one server are joined to a spatial framework housed on another server.

TJS is a web service that provides a standardized method to access and/or join attribute data to its associated geographic framework.Attribute data is a set of values that are referenced to a set of geographic features without including the spatial locations of those features. Geographic data attributes are normally presented as tabular data (such as population counts) that refer to a known framework (such as provinces), where the elements (the provinces) are referenced by a unique identifier (such as the province name). Population, temperature, and income are all examples of attribute data that could reference a geographic framework.

The geographic identifiers (or attributes) used in corporate databases usually reference a geographic (or spatial) framework. In this context a geographic framework is a partitioning of the surface of the earth into a set of management units. Municipalities, eco-regions, and watersheds are all examples of geographic frameworks which all have one thing in common – they contain a descriptor that can be used to uniquely identify any individual management unit – and that same descriptor, or identifier, is found in the corporate database. Here are some typical database contents along with their geographic frameworks:

• Sales by retail outlet or by municipality;
• Insurance payments by postal code;
• Telephone numbers by area code;
• Farms by Census Agricultural Region; or
• Students by school district.

To enable mapping or geospatial analysis, TJS offers a way to:

• Expose geographically identified data in corporate databases to other computers so that it can be found and accessed; and
• Merge that data with the data describing the geographic framework.

Optimizing Data Management

Tabular data to be exchanged via TJS must include a geographic identifier. The geographic identifier refers to a spatial feature found in a separate geospatial data set. In order to join tabular data to another dataset, both datasets must contain the same geographic identifier (i.e. Key Field). An example of such tabular data is a collection of population counts by city. The table includes the city name, but does not include any other geographic identifier. The city names can be used to join the population data to a layer in a GIS that contains the spatial coordinates for each city, in order to map the information or perform some sort of geospatial analysis.

TJS provides a simple standardized way to exchange attribute information that applies to a well-known geospatial dataset (a framework dataset). Attribute information delivered from a TJS can be used in a variety of ways, including the use of models to perform calculations, or visualization as a web map.

The advantages of the TJS standard is that it allows organizations to house their corporate data on systems that are optimized for the management of that data, and yet to take advantage of GIS technology to examine and analyze that data. In addition, it is:

• Simple to implement,
• Easy to use,
• Lightweight,
• Highly scalable, and
• Multi-purpose.

TJS allows corporate data to be maintained and updated closest to its source, and yet allows the latest data to be obtained when analysis is being performed, regardless of whether or not the geospatial system can make a direct connection to the corporate data management system. Exposing the data through a TJS allows corporate data managers to change their underlying database design and security safeguards without compromising access to data that should be accessible by other systems. In effect, TJS supports both distributed data management, as well as the distributed processing of geospatial data.

TJS Operations

TJS operations are the means by which a client can interact with a TJS implementation. Each TJS operation supports service discovery, data discovery and access, or the joining of attribute data to a spatial framework.

All TJS instances must implement the service discovery operation (GetCapabilities). TJS instances may choose to implement the data discovery and access operations, or the data joining operations, or both. When implementing any of these groups of operations, all of the operations in the grouping must be implemented.

Service Discovery Operations (mandatory)

• 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. This operation also supports negotiation of the standard version being used for client-server interactions.

To request a TJS capabilities document, a client may issue the following KVP-encoded GetCapabilities operation request with minimum contents:

http://foo.bar/foo&service=TJS&request=GetCapabilities

Data Access Operations (optional)

TJS includes four operations that support the retrieval of geospatial attribute data. The actual delivery of attribute data is performed via the GetData operation. Several related metadata operations return information about the attribute data that the TJS can deliver:

• DescribeDatasets- Allows a client to obtain general descriptions of the attribute data tables which are available from the server. Servers should implement an HTTP GET transfer for this operation using KVP encoding. The KVP encoding of this request must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST. An example of a valid DescribeDatasets operation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeDatasets&
FrameworkURI=http://foo.bar2/Provinces/2001&
Language=en-CA

• DescribeData - Allows a client to obtain a list describing the specific data contents of the attribute data tables (i.e. the attributes) which are available from the server. Servers should implement an HTTP GET transfer for this operation, using KVP encoding. The KVP encoding of this request must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST. An example of a valid DescribeDataoperation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeData&
FrameworkURI=http://foo.bar2/Provinces/2001&
DatasetURI=http://foo.bar/2001Census/2001&

Language=en-CA

• DescribeFrameworks- Allows a client to obtain a list of the spatial frameworks for which geo-tabular data is available from the server. Servers should implement an HTTP GET transfer for this operation request, using KVP encoding. The KVP encoding must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST.An example of a DescribeFrameworks operation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeFrameworks&
Language=en-CA

• GetData- Allows a client to obtain a specific set of geo-tabular data. Servers should implement an HTTP GET transfer for thisoperation request, using KVP encoding. The KVP encoding must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST. An example of a valid GetData operation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=GetData&
FrameworkURI=http://foo.bar2/Provinces/2001&
DatasetURI=http://foo.bar/2001Census&
Attributes=cattlecalves,cows&
LinkageKeys=10-13,24,35,46-48&
XSL=http://foo.bar/xslt

The responses to these operations return dataset, framework and attribute metadata that describe the data available from the service instance. These responses can be used to populate service registries. If the TJS supports data access, then all of these operations are mandatory.

Data Joining Operations (optional)

TJS includes three operations that support the joining of attribute information with its geometry. The merging of data is performed via the JoinData operation. The related DescribeJoinAbilities operation returns information about the spatial frameworks to which attributes can be joined, while the DescribeKey operation returns the contents of the framework Key Field for a framework dataset. If the service instance supports data joining, then all of these operations are mandatory.

• DescribeJoinAbilities- Returns an XML document that identifies all of the spatial frameworks to which attribute data can be joined by the service instance. The description includes information that uniquely identifies each spatial framework, and descriptive information about each framework that can be used to support service discovery and populate service registries. Servers should implement an HTTP GET transfer for thisoperation request, using KVP encoding. The KVP encoding must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST. An example of a DescribeJoinAbilities operation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeJoinAbilities&
Language=en-CA

The normal response to a valid DescribeJoinAbilitiesoperation request will be a JoinAbilitiesdata structure, which contains descriptions of one or more frameworks to which data tables can be joined by this server.

• DescribeKey - Returns an XML document that identifies all of the keys for a spatial framework to which data can be joined by the service instance. The description also includes descriptive information about the spatial framework. The listing can be used to debug the JoinDataoperation, or to build a new attribute dataset for the spatial framework. Servers should implement an HTTP GET transfer for thisoperation request, using KVP encoding. The KVP encoding must use the parameters specified in the standard. XML encoding of the request is optional, using HTTP POST. An example of a DescribeKey operation request KVP-encoded for HTTP GET is:

http://foo.bar/foo?

Service=TJS&
Version=1.0&
Request=DescribeKey&
FrameworkURI=http://foo.bar/foo&
Language=en-CA

The normal response to a valid DescribeKey operation request will be a FrameworkKeyDescription data structure, which lists the entire contents of the FrameworkKey field for which the JoinData operation is supported by the server.

• JoinData- Instructs the server to merge an attribute data table encoded in the Geographic Data Attribute Set (GDAS) format (i.e. obtainable via a GetData request) with its spatial framework. The server performs the join and prepares the output in the form requested by the client. The response includes the connection information required to access the output(s). Servers should implement an HTTP POST transfer for this operation request, using KVP encoding. The KVP encoding must use the parameters specified in the standard. Servers may also implement an HTTP POST transfer of the JoinDataoperation request using XML encoding, in accordance with the tjsJoinData_request.xsd XML schema. Note that the use of this XML encoding provides additional capabilities for this request by providing options for the GetData portion of the JoinDatarequest via either HTTP GET or POST. An example of a JoinData operation request KVP-encoded for HTTP POST is:

Service=TJS&
Version=1.0&
Request=JoinData&
Language=en-CA&
FrameworkURI=http://foo.bar2/foo& 
GetdataURL="http://foo.bar2/foo& 
StylingURL="http://foo.bar3/foo&
StylingIdentifier=SLD_1.0

The normal response to a valid JoinData operation request will be a JoinDataResponse data structure, which contains a copy of the request, execution status, and references to the outputs created by the service.

Additional Information Resources

The OpenGIS® Georeferenced Table Joining Service Implementation Standard provides a standard interface definition for a TJS, and applies to the creation and use of a TJS. The standard includes the definition of all TJS requests and responses, including the specification of the GDAS encoding format using eXtensible Markup Language (XML 1.0). The standard does not address the archiving, cataloging, discovery or retrieval of GDAS or other TJS XML documents.

The website, http://geoprocessing.info/tjsdoc/index, provides significant background concerning TJS, a Glossary of terminology and step-by-step information to register and access TJS.