TJS Concepts

geoprocessing.info

Home  |  Terms of use

TJS Concepts


Contents

What is TJS?

The need for web services based on TJS

TJS web services

Advantages of TJS

Types of TJS applications

Providing access to data via TJS

Where did TJS come from?



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

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.

TJS was originally called the Geographic Linkage Service.

Top


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.

Top


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:

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.

Top


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:

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

Top


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.

Modelling

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.

Top


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:

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.

Top


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.

Top