A Prototype Spatial Object Transfer Format (SOTF) Peter Woodsford Laser-Scan Ltd., Cambridge, UK. 6th EC-GI & GIS Workshop, Lyon, France, June 2000.

SOTF - Introduction Many agencies now handle GeoInfo as Objects Spatial Object Transfer Standard SOTF is a transfer format for geospatial data optimised for: transfer across ‘non-live’ connections archive active object store to warehouse connections OGC’s Geography Markup Language (GML) - both XML encoding of geospatial data

SOTF - Introduction (cont) Origins in NIMA research contract Survey of current transfer standards Requirements specification neutral, industry standard technology remedying key shortcomings incremental update support for value added flexible as regards topology 2D and 3D (and potentially, temporal)

What is SOTF? A data store imports/exports SOTF datasets, SOTF describes these processes and the demands on the data store Currently an SOTF dataset is an XML encoding for geospatial data similar to GML very similar to [the first version of] SFXML

Use of XML Current prototype uses XML v1.0 parallels initial OGC offerings Area of rapid development particularly for schema definition, a key part of SOTF Indexing not key to transfer format, but technology is emerging Currently verbose, but emerging compression techniques (zip does a lot)

Why the word ‘object’? SOTF has an object-oriented schema with: features and feature types properties and data types SOTF supports multiple geometric properties per feature SOTF supports both spatial and aspatial feature types

Why the word ‘object’? SOTF supports multiple inheritance of feature types SOTF supports light-weight, binary feature relationships SOTF is designed to handle complex, structured geospatial data; it does not support methods and behaviour.

SOTF data store requirements Designed to work with both [object-]relational and object-oriented data stores An SOTF dataset always includes an explicit schema Currently SOTF does this with a fixed DTD GML profile 1 would not be suitable To support export of an SOTF dataset a data store should provide feature identifiers that persist between exports may provide ability to retain a previous state

SOTF and topology support SOTF has no in-built topology support However topological feature types (e.g. faces, edges and nodes) can be described using base SOTF concepts To work between multiple data stores it is necessary to agree on a common ‘topological sub-schema’ A sub-schema describes an optional, but standardised, part of the schema

Data producers and data consumers These two communities have differing requirements: large vs. small geographic extent fixed schema vs. ad-hoc inclusion of extra data time tabled release vs. spontaneous demand SOTF provides a number of mechanisms to address these differences

Incremental update Level of granularity is the feature Tag features as ‘new’, ‘modified’ or ‘deleted’ Requires persistent feature identifiers Requires a data store to be able to ‘difference’ states

Area-of-Interest Data supplier SOTF dataset Data consumer

Area-of-Interest SOTF works at the level of features granularity of incremental update granularity of references SOTF does not require features to be split along artificial tile boundaries To support ‘area-of-interest’ SOTF requires features to support the concepts of extent and dependency in the data store.

Identifying features for export

Combining SOTF datasets Data supplier (with pre-defined ‘tile’ structure) Pre-generated, stock-piled, set of SOTF datasets Data consumer combines SOTF datasets

Value Adding SOTF provides rules to determine if two schema are compatible. Since SOTF datasets always include a schema this allows: schema evolution at the data producer to be communicated to the data consumer ‘compatible’ additions to the schema to be carried out by the data consumer in support of value-adding update does not invalidate value-added data

Summary - key techniques Incremental (or change-only) update depends on persistent feature (object) ID’s Support for export ‘area-of-interest’ avoids ‘tiling’ Can be combined at receiver permits ‘stockpiling’ by issuer Supports value-adding possible through explicit schema description

SOTF current status SOTF has been developed to a working prototype by Laser-Scan under contract from NIMA uses subset of Digital Nautical Chart data demonstrates the key techniques NIMA are keen to see further development of something by somebody that addresses these requirements provided: it is compatible with emerging standards such as GML there is interest from a wider community

SOTF future status Concepts under consideration for the evolution of GML within OGC – plays into Web access Possible definition of content for Transaction Encoding Specification - Interoperability Possible unifying role in emerging set of XML- based transfer formats - Transfer Up to the community!