A Prototype Spatial Object Transfer Format (SOTF)

1. 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.

2. 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

3. 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)

4. 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

5. 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)

6. 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

7. 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.

8. 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

9. 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

10. 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

11. 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

12. Data supplier Data consumer SOTF dataset Area-of-Interest

13. 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.

14. Identifying features for export

15. Identifying features for export

16. Identifying features for export

17. Identifying features for export

18. Data supplier (with pre-defined ‘tile’ structure) Pre-generated, stock-piled, set ofSOTF datasets Data consumercombines SOTF datasets Combining SOTF datasets

19. 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

20. 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

21. 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

22. 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!