1v.in.ogr(1)                   Grass User's Manual                  v.in.ogr(1)
2
3
4

NAME

6       v.in.ogr   -  Imports  vector  data  into  a GRASS vector map using OGR
7       library.
8

KEYWORDS

10       vector, import, OGR, topology, geometry, snapping, create location
11

SYNOPSIS

13       v.in.ogr
14       v.in.ogr --help
15       v.in.ogr   [-flc2tojrewi]   input=string    [layer=string[,string,...]]
16       [output=name]   [spatial=xmin,ymin,xmax,ymax[,xmin,ymin,xmax,ymax,...]]
17       [where=sql_query]      [min_area=float]      [type=string[,string,...]]
18       [snap=float]    [location=name]    [columns=name[,name,...]]    [encod‐
19       ing=string]   [key=string]   [geometry=name]   [--overwrite]   [--help]
20       [--verbose]  [--quiet]  [--ui]
21
22   Flags:
23       -f
24           List supported OGR formats and exit
25
26       -l
27           List available OGR layers in data source and exit
28
29       -c
30           Do not clean polygons (not recommended)
31
32       -2
33           Force 2D output even if input is 3D
34           Useful if input is 3D but all z coordinates are identical
35
36       -t
37           Do not create attribute table
38
39       -o
40           Override projection check (use current location’s projection)
41           Assume  that  the  dataset  has  the same projection as the current
42           location
43
44       -j
45           Perform projection check only and exit
46
47       -r
48           Limit import to the current region
49
50       -e
51           Extend region extents based on new dataset
52           Also updates the default region if in the PERMANENT mapset
53
54       -w
55           Change column names to lowercase characters
56
57       -i
58           Create the location specified by the "location" parameter and exit.
59           Do not import the vector data.
60
61       --overwrite
62           Allow output files to overwrite existing files
63
64       --help
65           Print usage summary
66
67       --verbose
68           Verbose module output
69
70       --quiet
71           Quiet module output
72
73       --ui
74           Force launching GUI dialog
75
76   Parameters:
77       input=string [required]
78           Name of OGR datasource to be imported
79           Examples:
80           ESRI Shapefile: directory containing shapefiles
81           MapInfo File: directory containing mapinfo files
82
83       layer=string[,string,...]
84           OGR layer name. If not given, all available layers are imported
85           Examples:
86           ESRI Shapefile: shapefile name
87           MapInfo File: mapinfo file name
88
89       output=name
90           Name for output vector map
91
92       spatial=xmin,ymin,xmax,ymax[,xmin,ymin,xmax,ymax,...]
93           Import subregion only
94           Format: xmin,ymin,xmax,ymax - usually W,S,E,N
95
96       where=sql_query
97           WHERE conditions of SQL statement without ’where’ keyword
98           Example: income < 1000 and population >= 10000
99
100       min_area=float
101           Minimum size of area to be imported (square meters)
102           Smaller  areas  and  islands  are  ignored.  Should be greater than
103           snap^2
104           Default: 0.0001
105
106       type=string[,string,...]
107           Optionally change default input type
108           Options: point, line, boundary, centroid
109           Default:
110           point: import area centroids as points
111           line: import area boundaries as lines
112           boundary: import lines as area boundaries
113           centroid: import points as centroids
114
115       snap=float
116           Snapping threshold for boundaries (map units)
117           ’-1’ for no snap
118           Default: -1
119
120       location=name
121           Name for new location to create
122
123       columns=name[,name,...]
124           List of column names to be used instead of original names, first is
125           used for category column
126
127       encoding=string
128           Encoding value for attribute data
129           Overrides  encoding  interpretation,  useful  when  importing  ESRI
130           Shapefile
131
132       key=string
133           Name of column used for categories
134           If not given, categories are generated as unique values and  stored
135           in ’cat’ column
136
137       geometry=name
138           Name of geometry column
139           If not given, all geometry columns from the input are used
140

DESCRIPTION

142       v.in.ogr  imports  vector data from files and database connections sup‐
143       ported by the OGR library) into the current location and mapset.
144
145       If the layer parameter is not  given,  all  available  OGR  layers  are
146       imported as separate GRASS layers into one GRASS vector map. If several
147       OGR layer names are given, all these layers are  imported  as  separate
148       GRASS layers into one GRASS vector map.
149
150       The  optional  spatial  parameter  defines spatial query extents.  This
151       parameter allows the user to restrict the region to  a  spatial  subset
152       while  importing  the data. All vector features completely or partially
153       falling into this rectangle subregion are  imported.   The  -r  current
154       region  flag  is identical, but uses the current region settings as the
155       spatial bounds (see g.region).
156
157   Supported Vector Formats
158       v.in.ogr uses the OGR library which supports various vector  data  for‐
159       mats  including ESRI Shapefile, Mapinfo File, UK .NTF, SDTS, TIGER, IHO
160       S-57 (ENC), DGN, GML, GPX, AVCBin, REC, Memory, OGDI,  and  PostgreSQL,
161       depending  on  the  local OGR installation. For details see the OGR web
162       site. The -f prints a list of the vector formats supported by the  sys‐
163       tem’s  OGR (Simple Features Library). The OGR (Simple Features Library)
164       is part of the GDAL library, hence GDAL needs to be  installed  to  use
165       v.in.ogr.
166
167       The list of actually supported formats can be printed by -f flag.
168
169   Topology cleaning
170       Topology  cleaning on areas is automatically performed, but may fail in
171       special cases. In these cases, a snap threshold value is estimated from
172       the  imported  vector  data and printed out at the end. The vector data
173       can then be imported again with  the  suggested  snap  threshold  value
174       which  is  incremented  by powers of 10 until either an estimated upper
175       limit for the threshold value is reached or the  topology  cleaning  on
176       areas  was successful. In some cases, manual cleaning might be required
177       or areas are truly overlapping, e.g. buffers created with non-topologi‐
178       cal software.
179
180       The  min_area  threshold  value  is being specified as area size in map
181       units with the exception of latitude-longitude locations in which it is
182       being specified solely in square meters.
183
184       The  snap  threshold  value  is  used to snap boundary vertices to each
185       other if the distance in map units between two vertices is  not  larger
186       than  the  threshold. Snapping is by default disabled with -1. See also
187       the v.clean manual.
188
189   Overlapping polygons
190       When importing overlapping polygons, the overlapping parts will  become
191       new areas with multiple categories, one unique category for each origi‐
192       nal polygon. An original polygon will thus  be  converted  to  multiple
193       areas  with  the same shared category. These multiple areas will there‐
194       fore also link to the same entry in the attribute table. A single cate‐
195       gory  value  may  thus  refer  to  multiple non-overlapping areas which
196       together represent the original polygon overlapping with another  poly‐
197       gon.  The original polygon can be recovered by using v.extract with the
198       desired category value or where statement and the -d flag  to  dissolve
199       common boundaries.
200

Location Creation

202       v.in.ogr  attempts  to  preserve  projection information when importing
203       datasets if the source format includes projection information,  and  if
204       the  OGR  driver  supports it.  If the projection of the source dataset
205       does not match the projection of the  current  location  v.in.ogr  will
206       report  an  error  message  ("Projection  of dataset does not appear to
207       match current location").
208
209       If the user wishes to ignore the difference between the apparent  coor‐
210       dinate  system  of  the  source data and the current location, they may
211       pass the -o flag to override the projection check.
212
213       If the user wishes to import the data with the full projection  defini‐
214       tion,  it is possible to have v.in.ogr automatically create a new loca‐
215       tion based on the projection and extents of the file being  read.  This
216       is accomplished by passing the name to be used for the new location via
217       the location parameter.  Upon completion of the command, a new location
218       will  have  been created (with only a PERMANENT mapset), and the vector
219       map will have been imported with the indicated  output  name  into  the
220       PERMANENT mapset.
221
222       An interesting wrapper command around v.in.ogr is v.import which repro‐
223       jects (if needed) the vector dataset during import to the projection of
224       the current location.
225

NOTES

227   Table column names: supported characters
228       The characters which are eligible for table column names are limited by
229       the SQL standard. Supported are:
230       [A-Za-z][A-Za-z0-9_]*
231       This means that SQL neither supports ’.’ (dots) nor ’-’ (minus) nor ’#’
232       in  table  column names. Also a table name must start with a character,
233       not a number.
234
235       v.in.ogr converts ’.’, ’-’ and ’#’ to ’_’ (underscore)  during  import.
236       The  -w  flag changes capital column names to lowercase characters as a
237       convenience for SQL usage (lowercase column names  avoid  the  need  to
238       quote them if the attribute table is stored in a SQL DBMS such as Post‐
239       greSQL). The columns parameter is used to define new column names  dur‐
240       ing import.
241
242       The  DBF  database  specification limits column names to 10 characters.
243       If the default DB is set to DBF and the input data contains longer col‐
244       umn/field  names,  they  will be truncated. If this results in multiple
245       columns with the same name then v.in.ogr will  produce  an  error.   In
246       this  case  you  will  either  have  to  modify  the  input data or use
247       v.in.ogr’s columns parameter to rename  columns  to  something  unique.
248       (hint:  copy and modify the list given with the error message).  Alter‐
249       natively, change the local DB with db.connect.
250
251   File encoding
252       When importing ESRI Shapefiles  the  OGR  library  tries  to  read  the
253       LDID/codepage setting from the .dbf file and use it to translate string
254       fields to UTF-8. LDID "87 / 0x57" is treated as ISO8859_1 which may not
255       be  appropriate  for many languages. Unfortunately it is not clear what
256       other values may be appropriate (see example below). To change encoding
257       the  user can set up SHAPE_ENCODING environmental variable or simply to
258       define encoding value using encoding parameter. Note that recoding sup‐
259       port is new for GDAL/OGR 1.9.0.
260
261       Value for encoding also affects text recoding when importing DXF files.
262       For other formats has encoding value no effect.
263
264   Defining the key column
265       Option key specifies the column name used for feature categories.  This
266       column must be integer. If not specified, categories numbers are gener‐
267       ated starting with 1 and stored in the column named "cat".
268
269   Supports of multiple geometry columns
270       Starting with GDAL 1.11 the library supports multiple geometry  columns
271       in  OGR.  By  default  v.in.ogr  reads  all geometry columns from given
272       layer. The user can choose desired geometry column by geometry  option,
273       see example below.
274
275   Latitude-longitude data: Vector postprocessing after import
276       For  vector  data  like  a  grid, horizontal lines need to be broken at
277       their intersections with vertical lines (v.clean ... tool=break).
278

EXAMPLES

280       The command imports various vector formats:
281
282   SHAPE files
283       v.in.ogr input=/home/user/shape_data/test_shape.shp output=grass_map
284       Alternate method:
285       v.in.ogr input=/home/user/shape_data layer=test_shape output=grass_map
286       Define encoding value for attribute data (in  this  example  we  expect
287       attribute  data  in Windows-1250 encoding; ie. in Central/Eastern Euro‐
288       pean languages that use Latin script, Microsoft Windows encoding).
289       v.in.ogr input=/home/user/shape_data/test_shape.shp output=grass_map encoding=cp1250
290
291   MapInfo files
292       v.in.ogr input=./ layer=mapinfo_test output=grass_map
293
294   Arc Coverage
295       We import the Arcs and Label points, the module  takes  care  to  build
296       areas.
297       v.in.ogr input=gemeinden layer=LAB,ARC type=centroid,boundary output=mymap
298
299   E00 file
300       See also v.in.e00.
301
302       First  we  have to convert the E00 file to an Arc Coverage with ’avcim‐
303       port’ (AVCE00 tools, use e00conv first in case that avcimport fails):
304       avcimport e00file coverage
305       v.in.ogr input=coverage layer=LAB,ARC type=centroid,boundary output=mymap
306
307   SDTS files
308       You have to select the CATD file.
309       v.in.ogr input=CITXCATD.DDF output=cities
310
311   TIGER files
312       v.in.ogr input=input/2000/56015/ layer=CompleteChain,PIP output=t56015_all \
313       type=boundary,centroid snap=-1
314
315   PostGIS tables
316       Import polygons as areas:
317       v.in.ogr input="PG:host=localhost dbname=postgis user=postgres" layer=polymap \
318       output=polygons type=boundary,centroid
319       If the table containing the polygons are in a specific schema, you  can
320       use:
321       v.in.ogr input="PG:host=localhost dbname=postgis user=postgres" \
322       layer=myschema.polymap \
323       output=polygons type=boundary,centroid
324       Generally,  v.in.ogr just follows the format-specific syntax defined by
325       the OGR library.
326
327   OpenStreetMap (OSM)
328       OSM data are available in .osm (XML based) and .pbf (optimized  binary)
329       formats. The .pbf format is recommended because file sizes are smaller.
330       The OSM driver will categorize features into 5 layers :
331
332           ·   points: "node" features that have significant tags attached.
333
334           ·   lines: "way" features that are recognized as non-area.
335
336           ·   multilinestrings:  "relation"  features  that  form  a   multi‐
337               linestring(type = ’multilinestring’ or type = ’route’).
338
339           ·   multipolygons:  "relation"  features  that  form a multipolygon
340               (type = ’multipolygon’ or type = ’boundary’),  and  "way"  fea‐
341               tures that are recognized as area.
342
343           ·   other_relations:  "relation" features that do not belong to any
344               of the above layers.
345       It is recommended to import one layer at a time.
346
347       Import of OSM data requires a  configuration  file,  defined  with  the
348       OSM_CONFIG_FILE  configuration  option.  In the data folder of the GDAL
349       distribution, you can find a osmconf.ini file that can be customized to
350       fit  your  needs.  See  OSM map features for keys and their values. You
351       should set "other_tags=no" to avoid problems with  import  or  querying
352       the  imported vector. Once a OSM_CONFIG_FILE has been created, OSM data
353       can be imported with e.g.
354       export OSM_CONFIG_FILE=/path/to/osmconf.ini
355       v.in.ogr input=name.pbf layer=lines output=osm_data
356
357   Oracle Spatial
358       Note that you have to set the environment-variables  ORACLE_BASE,  ORA‐
359       CLE_SID, ORACLE_HOME and TNS_ADMIN accordingly.
360       v.in.ogr input=OCI:username/password@database_instance output=grasslayer layer=roads_oci
361
362   Multiple geometry columns
363       This  example shows how to work with data which contain multiple geome‐
364       try per feature. The number of geometry  columns  per  feature  can  be
365       checked by v.external together with -t flag.
366       v.external -t input=20141130_ST_UKSH.xml.gz
367       ...
368       Okresy,point,1,DefinicniBod
369       Okresy,multipolygon,1,OriginalniHranice
370       Okresy,multipolygon,1,GeneralizovaneHranice
371       ...
372       In  our  example layer "Okresy" has three geometry columns: "Definicni‐
373       Bod",  "OriginalniHranice"  and  "GeneralizovanaHranice".  By   default
374       v.in.ogr reads data from all three geometry columns. The user can spec‐
375       ify desired geometry column by geometry option, in this case the module
376       will  read  geometry  only  from  the specified geometry column. In the
377       example below, the output vector map will contain only  geometry  saved
378       in "OriginalniHranice" geometry column.
379       v.in.ogr input=20141130_ST_UKSH.xml.gz layer=Okresy geometry=OriginalniHranice
380

WARNINGS

382       If a message like
383       WARNING: Area size 1.3e-06, area not imported
384       appears,  the  min_area  may be adjusted to a smaller value so that all
385       areas are imported. Otherwise tiny areas are filtered out during import
386       (useful to polish digitization errors or non-topological data).
387
388       If a message like
389       Try to import again, snapping with at least 1e-008: ’snap=1e-008’
390       appears,  then  the map to be imported contains topological errors. The
391       message suggests a value for the snap parameter to be tried.  For  more
392       details, see above in Topology Cleaning.
393

ERROR MESSAGES

395   SQL syntax errors
396       Depending  on the currently selected SQL driver, error messages such as
397       follows may arise:
398       DBMI-SQLite driver error:
399       Error in sqlite3_prepare():
400       near "ORDER": syntax error
401       Or:
402       DBMI-DBF driver error:
403       SQL parser error:
404       syntax error, unexpected DESC, expecting NAME processing ’DESC
405       This indicates that a column name in the input dataset corresponds to a
406       reserved  SQL word (here: ’ORDER’ and ’DESC’ respectively). A different
407       column name has to be used in this case. The columns parameter  can  be
408       used  to  assign  different  column  names on the fly in order to avoid
409       using reserved SQL words.  For a list of SQL reserved words for  SQLite
410       (the default driver), see here.
411
412   Projection errors
413       Projection of dataset does not appear to match the current location.
414       Here you need to create or use a location whose projection matches that
415       of the vector data you wish to import. Try using location parameter  to
416       create  a  new  location  based  upon the projection information in the
417       file. If desired, you can then re-project it to another  location  with
418       v.proj.
419

REFERENCES

421           ·   OGR vector library
422
423           ·   OGR vector library C API documentation
424

SEE ALSO

426        db.connect, v.clean, v.extract, v.build.polylines, v.edit, v.external,
427       v.import, v.in.db, v.in.e00, v.out.ogr
428
429       GRASS GIS Wiki page: Import of Global datasets
430

AUTHORS

432       Original author: Radim Blazek, ITC-irst, Trento, Italy
433       Location and spatial extent support by Markus Neteler and Paul Kelly
434       Various improvements by Markus Metz
435       Multiple geometry columns support  by  Martin  Landa,  OSGeoREL,  Czech
436       Technical University in Prague, Czech Republic
437
438       Last changed: $Date: 2018-10-14 13:08:21 +0200 (Sun, 14 Oct 2018) $
439

SOURCE CODE

441       Available at: v.in.ogr source code (history)
442
443       Main  index  | Vector index | Topics index | Keywords index | Graphical
444       index | Full index
445
446       © 2003-2019 GRASS Development Team, GRASS GIS 7.4.4 Reference Manual
447
448
449
450GRASS 7.4.4                                                        v.in.ogr(1)
Impressum