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



NNAAMMEE
       vv..iinn..sshhaappee - Read an ArcView Shapefile
       _(_G_R_A_S_S _V_e_c_t_o_r _P_r_o_g_r_a_m_)

SSYYNNOOPPSSIISS
       vv..iinn..sshhaappee


       vv..iinn..sshhaappee[[--lloouudd]]  iinnppuutt==_n_a_m_e [oouuttppuutt==_n_a_m_e] [vveerrbboossee==_d_e_b_u_g _l_e_v_e_l] [lloogg--
       ffiillee==_n_a_m_e] [ssnnaappddiisstt==_s_n_a_p _d_i_s_t_a_n_c_e] [ssccaallee==_o_r_i_g_. _s_c_a_l_e] [aattttrriibbuuttee==_c_a_t_-
       _e_g_o_r_y _n_u_m_b_e_r] [llaabbeell==_c_a_t_e_g_o_r_y _l_a_b_e_l]

DDEESSCCRRIIPPTTIIOONN
       The  _v_._i_n_._s_h_a_p_e	program  is  designed  to  import  ArcView Shapefiles.
       _v_._i_n_._s_h_a_p_e will be run non-interactively if the user specifies  program
       arguments on the command line. Alternately, the user can simply type:


       vv..iinn..sshhaappee

       on  the	command line without program arguments. In this case, the user
       will be prompted for parameter values using  the  standard  GRASS  user
       interface described in the manual entry for _p_a_r_s_e_r.

FFEEAATTUURREESS
       By  default  Grass files created have the name extracted from the base-
       name of the shapefile. This can be over-ridden by supplying a value  to
       the _o_u_t_p_u_t option, which must be a legal name.


       The  current  version  is  more	robust than the module available up to
       Spring 2002.  The emphasis is now  to  concentrate  on  maintaining  an
       effective  shape file import filter.  To assist this, features that are
       really extensions of the basic aim have	been  removed.	 Selection  of
       features  with  particular  attributes  can still be extracted to a new
       file with _v_._e_x_t_r_a_c_t. There is also less need for posterior  error  cor-
       rection	now,  as the current module filters out some potentially prob-
       lematic shapes at the point of  import,	and  so,  will	always	insert
       incoming  data  into  the final map. If a map fails to build because of
       topological errors, the problem can be tracked down using  _v_._d_i_g_i_t  and
       fixed.  Formerly,  the  module  attempted  many kinds of fixes, however
       there were many complaints about imported maps being modified  or  cor-
       rupted by the process, so we now leave the fixing of such errors to the
       user.
       The snap distance, which always has a small default value if  not  sup-
       plied,  creates a microgrid of cells in the import map region. Only one
       vertex is ever assigned to a particular cell.  If  a  later  vertex  is
       added  that  is in the same cell, it is considered co-incident with the
       first. When a link is added between two vertices, it  is  recorded  and
       the  same  link	is  not added twice. The snap distance is also used to
       define the co-incidence of other spatial entities, for example edges of
       bounding boxes. This snap distance has no relation to the snap distance
       defined for the dig_plus map. (This still needs some improvement).

OOPPTTIIOONNSS
   FFllaaggss::
       --ll     Force an area (polygon theme) import to be imported as lines  aass
	      iiss. This option can be used to create an outline of the original
	      boundaries even if the map is bad. This option  is  ignored  for
	      other types of import.

       --oo     Allow over-write of existing vector map.

       --uu     If  the  record number is used as the attribute, several 'parts'
	      of the same does not currently support  compound	objects.  This
	      may  be  what you want, but it might not. To assign a unique and
	      sequential record number, as attribute, to each area choose this
	      option. So, this option is ignored if the _a_t_t_r_i_b_u_t_e is set.

	      NNoottee:: This can cause a subtle difference even if applied to cov-
	      erages without compound objects, as it always applies a  sequen-
	      tial  ID value to each successively imported object. Without the
	      option,  it is the record number in the original that  is  used,
	      which  can  skip	values if there are NNUULLLL shapes, because GRASS
	      ignores the latter.  This may be important if you  plan  to  use
	      the attribute as a row ID in an external database or _d_b_m_i.

       --dd     List fields in DBF file


   PPaarraammeetteerrss::
       iinnppuutt=_f_i_l_e_n_a_m_e
	      Name  of	input shape file. Provide a full path name or the name
	      of a file in the current directory. Any of  the  full  pathname,
	      basename, or prefix only will suffice.

       oouuttppuutt=_f_i_l_e_n_a_m_e
	      Name  of	vector	map  to  be  created (default: prefix of shape
	      file). By default prefix of shape file name is used.

       vveerrbboossee=_i_n_t_e_g_e_r
	      Number between 0 (minimal report of fatal errors	and  essential
	      warnings)  and  3 (very verbose log - reports most data transfer
	      operations and some intermediate steps).	The default is 11.

       llooggffiillee=_f_i_l_e_n_a_m_e
	      Name of file[path] where log info will be written.  By  default,
	      log info is directed to _s_t_d_e_r_r, which is also used (with a warn-
	      ing) if the log filepath is invalid or not writable.

       ssnnaappddiisstt=_f_p_-_n_u_m_b_e_r
	      A grid resolution can be defined within which adjacent  vertices
	      will snap.

	      NNoottee::The	vertices  do  not  snap  to the grid. All the vertices
	      inside a grid cell snap to one  of  their  number  (usually  the
	      first).	This  value defaults to 1.0e-10 ground units. In fact,
	      it will never allow a value that is  less.  This	is  still  not
	      quite   right,  but  errors  caused  by  it  are	astronomically
	      unlikely, and are easily fixed manually, which must be  set  off
	      against the import process increasing in duration by a factor of
	      several if the snapping procedure was perfectly correct.	Really
	      effective  snapping  must await the development of spatial query
	      functions.  Therefore it will not be changed at this stage.

       ssccaallee=_i_n_t_e_g_e_r
	      This sets an original scale that will be specified in the header
	      of  the  vector  map file produced.  It can be edited later with
	      vv..ddiiggiitt.	The value defaults to 1:2400. The value  affects  some
	      behaviour  of  _v_._d_i_g_i_t including proper building, so may have to
	      be played with.  Of course it can be reset by _v_._d_i_g_i_t  following
	      import.

       aattttrriibbuuttee=_n_a_m_e
	      Name  of	the  input  field  to  use  as	the category number in
	      dig_att.	Defaults to using the record ID number as  a  category
	      value  if  no value is assigned or a non-numeric field is given.
	      If the field is floating-point the value is rounded to the near-
	      est integer.

       llaabbeell==_n_a_m_e
	      Name  of	the  input  field  to  use  as	the  category label in
	      dig_cats. Only writes out results if a meaningful category field
	      is given, otherwise no action is taken. If the same attribute is
	      re-assigned a new category, the value is over-written.

BBUUGGSS AANNDD CCAAVVEEAATT
       There is no support for projection since the projection information  is
       not stored in SHAPE files.


       Multipatch  data  is not yet supported. Point data is now imported, but
       in the GRASS 5.0.x vector model, these  vector  'points'  have  limited
       utility.The  module  _s_._i_n_._s_h_a_p_e imports site data in a form that may be
       found more useful.


       The filtration process creates a large temp file to store the  imported
       data  and  a  significant amount of metadata about the imported points.
       This can be large in large files. It is deleted if the import  proceeds
       in  a  normal fashion, but will be left 'dangling' on abnormal termina-
       tion. This however is a quite general  problem  in  the	current  GRASS
       environment  model.  If	disk  space is available, this module will now
       import an unlimited size of map, though it is currently slow  on  large
       maps,  as there are many disk read/write operations. This is compounded
       by the lengthy build process, which  however  affects  all  vector  map
       builds.


       Area  and perimeter fields in input data may no longer be quite correct
       if the lines have been adjusted to correct topology problems.   But  if
       the user has not modified the file, the values should be correct. If in
       doubt, GRASS's own modules may be used to  generate  dimensional  data,
       for example _v_._r_e_p_o_r_t

EEXXAAMMPPLLEE
       Example:

       v.in.shape   in=map.shp	 out=map   attribute=OBJART   label=ALIASFOLIE
       scale=25000
       This command imports the shape  file  "map"  into  GRASS  at  scale  of
       1:25000	(since the scale is not stored in the shape file). "attribute"
       is the field name containing the record ID (if not set,	internal  num-
       bering  will  be done).	"label" is the field containing the associated
       text labels. Use the "-d" flag to get  the  list  of  fields  from  the
       "map.dbf" file.

SSEEEE AALLSSOO
       _m_._i_n_._e_0_0_,  _g_._m_a_p_s_e_t_s_, _g_._r_e_g_i_o_n_, _v_._d_i_g_i_t_, _v_._p_r_o_j_, _s_._i_n_._s_h_a_p_e_, _v_._s_u_p_p_o_r_t_,
       _v_._t_o_._r_a_s_t_, _v_._o_u_t_._s_h_a_p_e _v_._e_x_t_r_a_c_t _v_._r_e_p_o_r_t

AAUUTTHHOORRSS
       Frank Warmerdam (warmerda@home.com)
       Based on Shapelib (http://gdal.velocet.ca/projects/shapelib/).


       Markus Neteler

       added category support


       David Gray

       preprocessing to provide correct handling of polygon edges, labels  and
       correction of some topological errors. Also some new options q.v.
       Spring 2002: Rewrite of most of the code.

       _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_2_:_4_6 _$



GRASS 5.0							 v.in.shape(1)
