a prototype spatial object transfer format (sotf)

A Prototype Spatial Object Transfer Format (SOTF)

Peter Woodsford (peterw@lsl.co.uk)

Laser-Scan Ltd., Cambridge, UK.

www.laser-scan.com

6th EC-GI & GIS Workshop,

Lyon, France, 28-30 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 datasetData 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

Identifying features for export

Identifying features for export

Identifying features for export

Combining SOTF datasets

Data supplier (with pre-defined ‘tile’ structure) Pre-generated,

stock-piled, set of

SOTF datasetsData consumercombines 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!