1v.in.ogr(1) Grass User's Manual v.in.ogr(1)
2
3
4
6 v.in.ogr - Imports vector data into a GRASS vector map using OGR
7 library.
8
10 vector, import, OGR, topology, geometry, snapping, create location
11
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
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
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
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
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
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
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
421 · OGR vector library
422
423 · OGR vector library C API documentation
424
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
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
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)