Why would I use TJS? I can program this type of thing myself.
Why not just modify WFS and GML to support TJS functionality?
Is TJS the same as Geolinking?
Does using TJS mean we have to share our entire database?
Does using TJS mean we will have to give away our data for free?
How can my organization make its attribute data accessible?
Can I join multiple attribute to a common geometry at the same time?
Where is the Join operation performed?
Can a WPS request values of a TJS join for further processing?
Can TJS be used to tie WPS output values to WFS geometry?
Why would I use TJS? I can program this type of thing myself.
The main reason for using a standard or specification such as TJS is interoperability, which allows for easy sharing of information. By adopting a common standard to format and transfer the terabytes of data existing in multiple organizations on multiple systems, the data become easily accessible through the internet for all to benefit.
Table joining technology is endorsed by the Canadian Geospatial Data Infrastructure (CGDI), which in its tutorial gives some practical, day-to-day reasons for using CGDI-endorsed standards and specifications for geospatial data and services:
- Reduce development costs;
- Hide the complexity of components; and
- Permit GIS practitioners and developers to benefit from "plug and play" components.
Widening the focus, the CGDI also gives the following reasons for supporting standards and specifications:
- Wide-scale interoperability of web services;
- Increased availability, access and sharing of geospatial information;
- Efficient use of digital geospatial information and associated hardware and software systems;
- Seamless chaining of applications, data and services;
- Promotion of existing and evolving Canadian technology and expertise;
- Ensuring compliance of Canadian data products;
- Development of effective partnerships with other spatial data infrastructures; and
- Solutions for global delivery of geospatial information.
TJS was developed by the OpenGIS Consortium (OGC).
Why not just modify existing standards, such as WFS (Web Feature Service) and GML (Geography Markup Language) to support TJS functionality?
There are a number of reasons why TJS was created as a new specification.
- Attribute focus vs Spatial focus. TJS is focused on transmitting the attributes that describe spatial features, but without geography; WFS and GML are primarily designed to transmit the actual geography. The types of databases that contain these two disparate concepts are quite separate, so although geolinking is not likely to be needed when the two types of data are found together, it makes sense to have separate custom schemas for each type of data.
- New concept. WFS and GML do not accommodate the concept of geospatial frameworks or geolinked datasets, nor the metadata required to completely support these concepts. Although they could certainly be extended to completely handle geolinked data requirements, it makes more sense to have a simpler lightweight XML schema that is customized to deal with geolinked data.
- Single implementation standard. TJS is designed to specifically address the concept of separate geolinked datasets, frameworks, and their supporting metadata. Given the potential importance of geolinked data as a source of information for Web-based GIS activities, a separate specification was warranted.
- Simpler coding. The XML stream produced by TJS is much simpler, more intuitive, and easier to write, read, and debug compared to GML.
- No software requirement. It is easy to generate GDAS XML streams directly from corporate database management technology, whereas WFS and GML typically require installation of additional software.
Note that the use of TJS does not preclude the use of WFS or GML. For example, a TJS can be set up to merge a GDAS stream with a GML stream to produce an amended GML stream that incorporates the attribute information provided by GDAS.
Is TJS the same as Geolinking?
Yes. TJS is the successor to a suite of technology that was known as geolinking. TJS was developed over the period from 1999 to 2010. During that time it underwent a number of name changes. It was originally proposed as two separate specifications: the Geographic Data Access Service, and the Geolinking Service. These specifications were merged to form the Geographic Linkage Service, and then renamed to become the Table Joining Service.
The fundamental concepts have remained unchanged from the initial proposals, but TJS has incorporated a substantial number of improvements from a decade of interoperability experiments and testing.
Do we have to share our whole database? Our organization has a lot of sensitive information that not everybody should have access to.
Not everything has to be shared – you can select which data you wish to publish. Perhaps the best way to ensure security of your data is to implement TJS on a dedicated, isolated network, to which access is limited.
For example, Agriculture Canada works with some sensitive agricultural census data accessible only by its own scientists and analysts. TJS is used to make this data accessible to them via an internal network. Only the aggregated data or results of the modelling are made available to the public, via a separate TJS instance.
Do we have to give away our data for free?
No, using TJS does not mean that the data must be given away for free. In the case of government departments, it is encouraged to freely distribute the data to the taxpayers that support them. However, for commercial enterprises, an e-commerce module can be layered on top of TJS.
How can my organization make its attribute data accessible via TJS?
There are three things you need to do to make your geolinked data Web-accessible:
- Document the data. Determine which data and associated metadata you wish to publish. Depending on how your databases are structured and which TJS software you use, you may have some data restructuring and documentation work to do.
- Create the Application Program Interfaces (APIs) to your data. TJS relies on a lightweight XML schema called GDAS to exchange attribute information. If your needs are fairly simple, you might just want to create a GDAS file manually and publish it to a GDAS registry. If your datasets are more substantial, you can either have a developer create APIs to your corporate database system(s) to produce XML streams according to the TJS standard, or install software that supports TJS and populate its associated databases.
- Register your data. Use this registry to advertise your TJS instance. Search for data using this client.
Can I join multiple attribute to a common geometry at the same time?
Yes, you can. Multiple attributes from a single table can be joined to a common geometry in one operation, although the server may restrict the number of attributes that can be joined simultaneously. This restriction is advertised in the server's Capabilities document.
Joining data from multiple tables will require separate operations for each table. In order to create a single output that consists of data joined from multiple tables, the input data would have to be merged into a single GDAS representation prior to the TJS Join operation. Such merging could be accomplished via a WPS.
Where is the Join operation performed?
The Join operation is mediated by the TJS server, but can actually take place on another server, and the results of the join operation can be made available in a variety of formats.
Can a WPS request values of a TJS join (e.g. where polygons have been populated with corresponding attribute values) for further aggregation i.e. scale up / normalize, to calculate mean / average / totalsum / trends, algorithmic and geostatistical rendering, interpolation with other thematic layers?
In order to use the results of a TJS join in further geostatistical manipulations, the TJS server performing the join should be configured to output data via WFS.
Can TJS be used to tie WPS output values to WFS geometry?
TJS can be used to tie outputs from a WPS to the geometry hosted by a WFS. In order to do so, the outputs from the WPS must be in GDAS format, which is defined in the TJS spec. Also, the TJS performing the JoinData operation must be able to manipulate the database that supports the WFS server.
