What is TJS?

The Table Joining Service (TJS) is an OGC standard that defines how to join attribute data to its associated geographic framework, or framework data.

Attribute data refers to data that can be mapped, but is not directly attached to and bundled with geographic coordinates. Attribute data uses an identifier, found in a framework key field, to indicate the geographic feature to which it applies.

Framework data refers to data that describes the positioning on the surface of the earth of a set of geographic features such as countries. Framework data must include a framework key field, an identifier that allows attribute data to be attached to an individual geographic feature.

Examples of attribute data and associated geographic frameworks

  • Sales by municipality
  • Insurance payments by postal code
  • Inquiries by telephone area code
  • Farms by Census Agricultural Region
  • Students by school district

TJS offers a simple web-based method of finding, accessing, and using attribute data from multiple sources dynamically, in order to populate databases, perform analyses, and/or make maps.


The need for TJS

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 GIS. That is, the data contain geographically related information, but do not include their spatial description.

A vast number of data collections have remained undiscovered and/or underutilized by the geomatics community, primarily because until now there has not been an easy way to find and access all these data in a usable manner.

TJS provides a way to expose this corporate data to other computers through the internet. The data can be easily found and dynamically accessed from the source databases for mapping and inclusion in geospatial analysis models or other applications.


Advantages of TJS

The main advantage of TJS is interoperability. It allows organizations to house their corporate data on systems that are optimized for the management of that data, and yet allow themselves and others to take advantage of Geographic Information System (GIS) technology to examine and analyze that data. The TJS standard defines a set of data access operations that can be supported by any database management system, and a set of data joining operations that can be implemented by any GIS. Thus, TJS allows the latest data to be obtained when an analysis is being performed, regardless of whether or not the geospatial system is compatible with or directly connected to the corporate data management system.

Using TJS has other advantages:

  • Simple yet powerful. TJS uses standard HTTP and XML (eXtensible Markup Language) as a mechanism for data exchange; this makes it very lightweight, yet highly scaleable to be used for mapping, analysis, calculations, or data replication.
  • Exploits the power of distributed computing. TJS is designed to facilitate distributed data management, enabling distributed processing of geospatial data located anywhere on the Internet.
  • Fast, reliable access to "near real-time" information. Because it can be generated dynamically, the most up-to-date data can be accessed directly from the source organization responsible for its maintenance.
  • Flexibility with security. Exposing the data through 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.
  • Easy to find data. Exposing the data through TJS allows its metadata to be harvested into registries, thus making it easy to publish, find, and access attribute data and data joining services.

TJS owes its simplicity and power to the XML encoding it uses. This encoding is called Geographic Data Attribute Set, or "GDAS". All TJS operations create or use XML documents that are based on GDAS.


TJS web services

There are three primary operations that are streamlined through TJS, and which can become simple, fast, and totally seamless for an end-user:

  • Finding data. The GetCapabilities operation will return metadata describing the organization and the attribute data it has available to share. The metadata provide enough information for evaluation of whether or not the data will be suitable, as well as how and where the client can access the desired data.
  • Accessing the data. Using information from the metadata, the GetData operation can then be used to retrieve the requested attribute data.
  • Joining data to a framework. The JoinData operation is used to direct the TJS to access some particular attribute data, and join that information to the associated framework data, thus allowing the data to be visualized. The join does not have to be permanent – it may be virtual or temporary.

Attribute data that are so easily accessible through these web services offer unlimited possibilities for applications, particularly dynamic ones.


Types of TJS applications

Customized applications that were previously costly and time-consuming to create can now be made dynamically, using TJS with other OGC standards and clients.

Web mapping: create WMS layers "on-the-fly"

The most widely applicable use of TJS may be to support web mapping – in particular, the dynamic creation of Web Map Service (WMS) layers. Dynamic data from an XML stream produced by a TJS can be seamlessly merged with the associated framework data via the framework key field. The resulting layer can be stored or discarded after processing if data volatility is of concern.

TJS is designed to work as a signle up-front operation, before any WMS requests are made. When implemented in this way it takes some processing time to dynamically configure the WMS, but once configured the WMS behaves as quickly as any other WMS. A user would normally:

  1. discover the data with TJS DescribeData and related operations
  2. submit a TJS JoinData request (whereupon the TJS would submit a GetData request and then join the attribute data to the framework data and configure the WMS server), and
  3. submit WMS GetMap requests to the the map that was created by the TJS.

Examples of applications using dynamically generated WMS layers

Many types of simple mapping applications benefit from dynamic updates of WMS layers because they contain time-relevant data. Some examples are:

  • Avian flu cases by county
  • SARS cases by municipality
  • Real estate sales by neighbourhood
  • Traffic volume by road section
  • Environmental indicators by ecoregion

Desktop GIS

For a desktop GIS that supports WMS layers, the image can simply be imported as shown in the web mapping illustration above. However, with a TJS acting on data provided via a GDAS stream, a desktop GIS supported by a geospatial data warehouse may have its attribute data supplemented or amended for direct manipulation within the GIS.

Distributed spatial data processing

The GDAS encoding allows for the ability to do additional calculations with the data. For example, it is trivial to take two separate GDAS streams for the same framework data and calculate the differences between the two attributes, providing that result in the form of another GDAS stream.


When geospatial data is exposed to the Internet through a TJS, it is easy to feed that data into models such as climate change models. If a model is enabled with a TJS on the front end to accept data, and a TJS on the output end to provide results, it is easy to run different input scenarios through the model. This ultimately simplifies data management, and reduces the potential for errors in input data.

Data updates

TJS also allows for the ability to replicate databases across the Internet. A TJS can use GDAS streams provided by another TJS to regularly update the contents of a data warehouse and its associated metadata tables, based on the latest information available from the primary data warehouse.


Providing access to TJS data

You have a number of options in how you provide access to your data through TJS web services and applications built on top of this technology:

  • Keep it internal. There may be data that is only relevant to your organization, but which is used, manipulated or processed by different groups within the organization. In this case, the TJS can be provided on an internal web server and need not be accessible by those outside the organization.
  • Offer it for free. Certainly in the case of government departments, it is strongly encouraged to offer the data and applications for free. This is the most valuable approach because it encourages, rather than discourages, widespread use of the data.

    An additional benefit is that with the newly available data, easily and dynamically accessed through TJS, we can now reach entire segements of the population that have up till now been barred from using geospatial data because of the complexity of the technology and the difficulty in working with the data.
  • Charge for it. In the case of commercial enterprises whose business might entail collecting or providing value-added data, you can build an e-commerce layer on top of your TJS services.

No matter how you do it, the important thing is that your data be made accessible. For some information on how to start, go to the Implementing TJS pages on this site.


Where did TJS come from?

The first version of TJS was developed between 1999 and 2000 by Peter Schut of the Canadian Soil Information Service, as a way of simplifying the production of soil maps. TJS was originally based on dbase files. By 2003 TJS consisted of two separate specifications, the Geolinked Data Access Service (GDAS) which specified how attributes were encoded and accessed, and the Geolinking Service (GLS), which specified how GDAS data could be joined to spatial datasets. It was published as a set of OGC discussion documents in 2004 and incorporated into the Canadian Geospatial Data Infrastructure standards the same year.

By November 2005 both discussion documents had become some of the most popular downloads from the OGC website, and this observation triggered an OGC interoperability experiment that ran from 2006 - 2008. GDAS and GLS were combined into one specification and released to the public in a Request for Comments in 2009 and 2010. TJS became an official OGC standard in November 2010.


This page is sponsored by