OGR improperly sees SDTS module files as layers

[mcoletti@…]

SDTS data transfers are comprised of many modules stored in files.  OGR
currently incorrectly treats each of these files as layers.  The Catalog/Spatial
Domain (CATS) modules dictates the theme, or layer, for each of the transfer's
modules.  Fortunately for most available SDTS modules, each transfer is
typically for a single theme.

For SDTS files to be opened an accessed in a manner consistent with other
geospatial data types, OGR will have to scan the CATS module THEM subfields for
the different available layers; however for raster SDTS files, there exists the
Layer Definition file (LDEF) that will have records that correspond to each
raster layer.  Typically the CATS THEM subfields is either a simple name or an
'*' denoting a generic theme.  

Each "feature" in the transfer is a little more complicated to get at within a
vector SDTS. (For raster's it's a matter of cracking open the CELL modules to
get the data with appropriate metadata being found in the other modules as per
the SDTS spec.)  Annoyingly SDTS has a couple multiple methods for storing
things by feature.  One is to have each unique feature have a corresponding
record in a COMPOSITE module.  A National Hydrology Dataset (NHD) I have has
COMPOSITE modules corresponding to each entity type.  (E.g., STREAM/RIVER,
TUNNEL, SPILLWAY, etc.)  So each GetNextFeature() iteration would just grind
through the different COMPOSITE module records.  Alternatively one could treat
each spatial object as a feature and use the attribute pointers that each SDTS
spatial object has to find out what entity that spatial feature is a art of; and
then do a relational join for each attribute field value based on the data
dictionary/schema and data dictionary/domain values. So GetNextFeature() would
grind through each spatial module record while cross-referencing appropriately
via any primary attribute (and possibly secondary attribute) values.

Ugly, but pretty mechanical.

[Jukka Rahkonen]

By reading the driver manual page ​http://www.gdal.org/drv_sdts.html I suppose that the situation is still the same: "Each primary attribute, node (point), line and polygon module is treated as a distinct layer."

The link SDTS abstraction library on the driver page is dead: ​http://home.gdal.org/projects/sdts/index.html

[Jukka Rahkonen]

The Spatial Data Transfer Standard (SDTS)page at ​http://mcmcweb.er.usgs.gov/sdts/ is currently at this status: "Note: The information on this page is being retained for technical and historical reference only. The site is not under active maintenance and may include expired information and outdated links."

It makes me feel that SDTS is not very lively standard. If that's true then this ticket could probably closed as "wontfix".