Next Generation SDTS Observations

by David Arctur, Laser-Scan

During the SDTS Next Generation breakout session, several issues were discussed. These included (think of "A:" below as short for "Discussion" more than "Answer"):

1. What roles/purposes does SDTS need to serve in the foreseeable future?

- vendor-neutral archive;

- bulk transfer of large amounts of geospatial data which are impractical to transfer via OpenGIS;

- transfer of geospatial data in environments where OpenGIS interfaces are not available.

---

2. Will development of a new profile be sufficient for fixing the problems identified with SDTS?

A: Any changes to standard need to be introduced via profile first.

---

3. What key changes should be made to SDTS (partial discussion summarized; more extensive needed)?

A: --Fix known ambiguities in SDTS and TVP for describing features and cardinality of relationships;

--Add support for Unicode character set (as in most current ISO 8211);

--Support a complete set of geodetic datums, projections;

--Add record indexing, spatial indexing for performance (need further discussion on this)

---

4. Is topology needed within SDTS datasets?

A: --Strict topology limits availability (or raises cost) of software to work with the data;

--topological relationships in a given dataset may differ from that used by a given GIS;

--but topology is costly & error-prone to determine, and should be stored once determined;

--could the standard/profile/decoder software be defined in such a way that non-topological GIS software could still make use of the data at a meaningful level?

---

5. What other harmonization should be included?

A: --GDF, S57, VPF, DIGEST, other data models*? Some research has been doneon this harmonization by USGS already.

--SDTS metadata support, and FGDC or ISO metadata requirements also need to be reconciled.

--SDTS spatial objects should be harmonized with OpenGIS "well-known structures"

---

6. Is ISO 8211 still the best idea for physical encoding?

A: NIMA's VPF uses simpler structure; what are the tradeoffs?

---

7. What changes should be made to SDTS++ ?

A: Look into record indexing and spatial indexing.

In addition to the ones above, I've also raised the following issues for SDTS (discussed in an earlier session at the SDTS workshop, and in the attached URISA'97 paper):

---

8. Could/should SDTS be adapted to support multiple profiles within a dataset?

--This is to allow, say, a raster backdrop to be transferred along with a vector dataset, thus allowing a single set of global modules to support multiple profiles.

---

9. Could SDTS be adapted to support a standard form for referencing module records across different datasets?

--This is to allow feature-to-feature references even where they occur in different datasets.

---

10. Could SDTS be adapted to support a standard form for subtiling within a dataset?

--This is to preclude multiple different approaches for representing subtiles and cross-tile topology, which are presently not addressed in the current standard and profiles.

---

11. Could/should SDTS be adapted to support incremental updates to a base dataset, as is now possible with IHO's S57 version 3?

--Some discussion has suggested that incremental update is more appropriateto OpenGIS and shouldn't be designed into SDTS. But SDTS should be designed with the idea that OpenGIS may not be available or practical. Could incremental update be practically implemented within SDTS?

---

During the breakout session, some of these issues were addressed briefly, but significant discussion is still needed. All the issues listed here will be referred to one or more of three ad hoc working groups formed at the SDTS workshop:

1. SDTS Enhancements (led by Bill Harris)

2. SDTS Metadata Harmonization (led by Robin Fegeas for now, but to be handed off to Rick Pearsall?)

3. SDTS Object Profile (led by David Arctur)