v.in.sdts(1)		      Grass User's Manual		  v.in.sdts(1)



NNAAMMEE
       vv..iinn..ssddttss   -  Imports  SDTS vector data, conforming to the Topological
       Vector Profile, into GRASS, creating GRASS vector map(s) and associated
       attribute files ready to be installed in a relational database.
       _(_G_R_A_S_S _V_e_c_t_o_r _D_a_t_a _I_m_p_o_r_t_/_P_r_o_c_e_s_s_i_n_g _P_r_o_g_r_a_m_)

SSYYNNOOPPSSIISS
       vv..iinn..ssddttss
       vv..iinn..ssddttss hheellpp
       vv..iinn..ssddttss  [--iill]  ccaattdd=_n_a_m_e  [oouuttppuutt=_n_a_m_e]  [ddbbppaatthh=_n_a_m_e] [ddoommaaiinn=_n_a_m_e]
       [mmaapp=_n_a_m_e] [tthheemmee=_n_a_m_e] [mmaanniiffoolldd=_n_a_m_e]

DDEESSCCRRIIPPTTIIOONN
       _v_._i_n_._s_d_t_s creates one or more GRASS vector maps in the  current	mapset
       from  a	Spatial Data Transfer Standard dataset conforming to the Topo-
       logical	Vector	Profile  (TVP).   The  program	generates  GRASS  _d_i_g,
       _d_i_g___a_t_t,  and  _d_i_g___c_a_t_s files.  Also, if requested, files of attributes
       in database-ready form are created, along with  scripts	to  create  an
       approprate  SQL-compliant  relational  database, and load the attribute
       files into the new database.  Special database-ready  files  of	tables
       linking the attributes to the GRASS vector map layer or layers are also
       generated.


       The source SDTS dataset must be in the user's current  directory.   The
       files  that  make  up  the  dataset  are  listed in the dataset's Cata-
       log/Directory file (CATD); this file is specified by the user with  the
       ccaattdd parameter.


       _v_._i_n_._s_d_t_s creates maps in your current mapset, and will only import map
       data if there is correspondence between the current mapset's coordinate
       system  and  that  of the transfer set; in addition, for UTM (and State
       Plane), Zone designations must match.  These specifications can be dis-
       played  be  running _v_._i_n_._s_d_t_s in "Information only" mode.  "Information
       only" mode is automatically put in effect when  there  is  a  mis-match
       between source and target coordinate systems.


       An  SDTS  dataset may consist of one or several distinct map layers (or
       "2-D manifolds", in SDTS terminology), coinciding with one or more par-
       titions	of  the  earth's surface.  If a dataset contains more than one
       map layer, the grouping of object data into individual map layers,  and
       of  groups  of  map  layers, is specified in the Catalog/Spatial Domain
       (CATS) file, in terms of "domain", "map",  "theme",  and/or  "manifold"
       ("aggregate  object").	If available, this information is displayed to
       the user in "Information Only" mode.  The user can then either

       (1) import all the map layers in a
	      transfer at once, or (2) select a subset of  the	transfer  con-
	      sisting  of  one	or  more maps by specifying a domain name, map
	      name, etc.



CCOOMMMMAANNDD LLIINNEE OOPPTTIIOONNSS
   FFllaaggss::
       --ii     "Information-only" mode.	Information about the dataset and  any
	      individual  map layers in the dataset are displayed. No map lay-
	      ers or attribute	files  are  generated.	Information  displayed
	      includes	basic identifying data (TITLE of transfer dataset, map
	      date, dataset creation date, scale,  coordinate  system,	etc.).
	      For individual maps, any names found in the CATS file specifying
	      map, theme, domain, manifold, are  given.  Bounding  coordinates
	      for each map layer are also printed.
	      The  program  will also run in "information only" mode if (1) no
	      output name is specified,  or (2) the coordinate system, or,  in
	      the  case  of  UTM  and  State Plane, Zone, of the dataset to be
	      imported does not match the current mapset.

       --ll     Import object  link  table(s)  only;  do	not  create  attribute
	      tables.	If  this  flag	is set, and if ddbbppaatthh is set, only the
	      vector map (_d_i_g, _d_i_g___a_t_t, and _d_i_g___c_a_t_s) and the file  containing
	      the  database-ready  table  linking  the	vector	map  with  the
	      attribute tables will be created; the attribute files themselves
	      will not be created.  This option is useful if the user wants to
	      selectively import data layers from an SDTS dataset with	multi-
	      ple  maps.  One map could be imported with its object link table
	      and the full set of attributes; subsequent layers imported  with
	      the   "--ll"   option  would  avoid  recopying  the  full  set  of
	      attributes.




   PPaarraammeetteerrss::
       ccaattdd==_n_a_m_e
	      Full name of SDTS file containing the  Catalog/Directory	(CATD)
	      module for the source dataset. The file name format is specified
	      by SDTS and the TVP as _x_x_x_x_C_A_T_D_._D_D_F, where _x_x_x_x are 4 digits  or
	      upper-case letters or any combination therof. The CATD file must
	      be located along with the rest of the SDTS dataset in  the  cur-
	      rent  directory.	 The  CATD  file contains a listing of all the
	      dataset files, and is thus the necessary starting point for  the
	      transfer process.
	      Note  that  the  same  four-character prefix of the CATD file is
	      used for all files in the SDTS dataset. This prefix is also used
	      by  _v_._i_n_._s_d_t_s  for the naming of the output attribute files (see
	      _T_h_e _G_R_A_S_S_-_S_D_T_S _U_s_e_r _G_u_i_d_e for details.)



       oouuttppuutt==_n_a_m_e
	      name for output vector map layer.  If the SDTS dataset  contains
	      multiple	maps,  and  if no particular one is specified, causing
	      all the maps to be imported, maps will be distinguished by  name
	      plus numeric suffix. If not specified the module runs in "infor-
	      mation mode" (-i flag) and no output is written.



       ddbbppaatthh==_n_a_m_e
	      full path to location for placement of database-ready  attribute
	      files  preparatory  to  their installation in a relational data-
	      base.  Path must exist and be writable by the user. Setting  the
	      ddbbaatthh  parameter causes database-ready files to be created; oth-
	      erwise they are not created.



       ddoommaaiinn==_n_a_m_e

       mmaapp==_n_a_m_e

       tthheemmee==_n_a_m_e

       mmaanniiffoolldd==_n_a_m_e
	      if one or more  domain,  map,  theme,  or  manifold  ("aggregate
	      object")	names  are  given  in the SDTS dataset Catalog/Spatial
	      Domain (CATS) file, map layers so  designated  can  be  selected
	      with  the  appropriate  parameter. "Information only" mode lists
	      any such names found in the CATS file.




SSPPAATTIIAALL OOBBJJEECCTTSS IINN SSDDTTSS AANNDD GGRRAASSSS
       SDTS and the Topological Vector Profile define two basic types of  spa-
       tial  objects:  simple  spatial objects, i.e., lines,  polygons, nodes,
       etc.; and composite objects, which are made up of  one  or  more  other
       simple and/or composite spatial objects.  SDTS composite objects, which
       GRASS cannot handle directly, are imported as  records  in  RDBMS-ready
       tables.	Details on the mapping of simple and composite spatial objects
       between SDTS and GRASS may be found in the _G_R_A_S_S_-_S_D_T_S _U_s_e_r _G_u_i_d_e.



SSDDTTSS AATTTTRRIIBBUUTTEE IIMMPPOORRTT
       Only a brief explanation of SDTS attributes and v.in.sdts's handling of
       them is given here.  See the _G_R_A_S_S_/_S_D_T_S _U_s_e_r _G_u_i_d_e for details.


       SDTS  is  capable  of  substantial  attribute complexity.  SDTS distin-
       guishes between two basic kinds of attributes: primary  attributes  are
       related	directly  to spatial objects (simple or composite), while sec-
       ondary  attributes  are	related  to  primary  or  to  other  secondary
       attributes.   In  SDTS, attributes are stored in relational tables, and
       spatial objects may be linked to multiple attributes  in  one  or  more
       different  attribute tables.  The schema of an SDTS dataset--the number
       and kind of attribute fields and attribute tables,  and	the  relation-
       ships  among  attributes and objects--is not predefined by the Standard
       or the Profile, but is determined by the producer of the dataset.


       For most kinds of data likely to be  available  through	SDTS,  optimal
       access requires use of GRASS with a relational database management sys-
       tem.  In support of this, _v_._i_n_._s_d_t_s imports SDTS attribute tables in  a
       form  ready  for  use with your RDBMS.  It also produces SQL-compatible
       scripts to set up the relational database and install the data.


       _d_i_g___a_t_t _a_n_d _d_i_g___c_a_t_s _f_i_l_e_s_:  The  program  does	generate  _d_i_g___a_t_t  and
       _d_i_g___c_a_t_s  files,  and  for relatively simple SDTS datasets, i.e., those
       with  one-to-one  object-attribute  relationships   with   all	object
       attributes  in a single attribute table, an associated relational data-
       base is not necessary.  In addition, for  more  complex	datasets,  the
       _d_i_g___a_t_t	and _d_i_g___c_a_t_s files are constructed in such a way as to facili-
       tate post-import incorporation of  selected  data  from	the  attribute
       files for use without recourse to a relational database.  Specifically,
       the contents of the generated _d_i_g___a_t_t and _d_i_g___c_a_t_s files  are  as  fol-
       lows:



       _d_i_g___a_t_t
	      Contains	an  entry  for	each  attributed  non-composite object
	      (line, polygon, point). each entry will  be  assigned  a	unique
	      category	integer  value.  These integers, or feature-IDs (FID),
	      also uniquely identify the same spatial objects,	in  the  rela-
	      tional  database	object link table.  _d_i_g___c_a_t_s For datasets with
	      one-to-one object-attribute relationships and a  single  object-
	      related  attribute  module,  only  one  database-ready  "object-
	      attribute" file is created, and the _d_i_g___c_a_t_s records  are  given
	      the  same  content, as the generated database-ready file. Record
	      structure is as follows:
	      FID | obj_code | attr_code | attr. field 1 |...| attr. field n |
		(_o_b_j___c_o_d_e  and _a_t_t_r___c_o_d_e are codes, derived from record IDs in
	      the SDTS dataset, which function as keys	in  the  import  rela-
	      tional database. See _T_h_e _G_R_A_S_S_-_S_D_T_S _U_s_e_r _G_u_i_d_e for details.)


       For  other  datasets,  the _d_i_g___c_a_t_s file is identical in content to the
       generated GRASS-database object link table, and records would have  the
       structure:
       FID | obj_code	  or	FID | obj_code | attr_code


SSDDTTSS IIMMPPOORRTT AANNDD UUSSEE OOFF AA RREELLAATTIIOONNAALL DDAATTAABBAASSEE
       Full  discussion  of  this  topic  may  be found in the _G_R_A_S_S_-_S_D_T_S _U_s_e_r
       _G_u_i_d_e.

FFIILLEE NNAAMMEESS
       _v_e_c_t_o_r _m_a_p _n_a_m_e_: if the SDTS dataset contains a single map layer, or if
       a a single map layer from a multiple-map dataset, the name specified in
       output is used as is. Otherwise, the name is extended with integers  to
       specify the individual layers.  _r_e_l_a_t_i_o_n_a_l _d_a_t_a_b_a_s_e _f_i_l_e _n_a_m_e_s_: see the
       GRASS-SDTS User Guide.

SSEEEE AALLSSOO
       _m_._s_d_t_s_._r_e_a_d_,  _v_._i_n_._s_d_t_s_,  _v_._o_u_t_._s_d_t_s_,   _v_._s_d_t_s_._d_p_._c_p_,   _v_._s_d_t_s_._m_e_t_a_._c_p_,
       _v_._s_d_t_s_._m_e_t_a

AAUUTTHHOORRSS
       David Stigberg, U.S.Army Construction Engineering Research Laboratory
       Tin Qian, University of Illinois

       _L_a_s_t _c_h_a_n_g_e_d_: _$_D_a_t_e_: _2_0_0_2_/_0_6_/_1_7 _1_7_:_2_0_:_3_9 _$



GRASS 5.0							  v.in.sdts(1)
