Transcript No Slide Title

A Prototype Spatial Object Transfer
Format (SOTF)
Peter Woodsford ([email protected])
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 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
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
Data consumer
SOTF datasets
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 XMLbased transfer formats - Transfer
• Up to the community!