A Prototype Spatial Object Transfer Format (SOTF)
The Spatial Object Transfer Format (SOTF) is a standard designed for the optimal transfer of geospatial data, facilitating archival and active object store-to-warehouse connections. Developed under a NIMA research contract, SOTF employs an object-oriented schema that supports multiple geometric properties and offers robust mechanisms for incremental updates. The format is grounded in XML, with origins similar to OGC’s GML, and aims to address industry needs by allowing flexible schema evolution and value-adding capabilities. A working prototype has been developed, showcasing its key techniques.
A Prototype Spatial Object Transfer Format (SOTF)
E N D
Presentation Transcript
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
Data supplier Data consumer SOTF dataset Area-of-Interest
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.
Data supplier (with pre-defined ‘tile’ structure) Pre-generated, stock-piled, set ofSOTF datasets Data consumercombines SOTF datasets Combining 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!
