GIS/MEA582: Geospatial Modeling and Analysis

Import and export of data from different sources in GRASS GIS

GRASS GIS project can contain data only in one coordinate reference system (CRS) in order to have full control over reprojection and avoid issues coming from on-the-fly reprojection.

When starting a project, decide which CRS you will use. Create a new project using Project Wizard (accessible from GRASS GIS start-up page). Specify desired CRS either by providing EPSG code (can be found e.g. at epsg.io) or by providing a georeferenced file (such as Shapefile) which has the CRS you want.

Importing data in common vector and raster formats

For basic import of raster and vector files, use r.import and v.import, respectively. These modules will reproject the input data if necessary. If the input data's CRS matches the project's CRS, we can use r.in.gdal or v.in.ogr for importing raster and vector.

Alternatively, you can use a two-step approach for the cases when the data's CRS doesn't match the project's CRS. First create a new temporary project based on the CRS of the data you want to import, switch to this project and then use r.in.gdal or v.in.ogr to import raster and vector data, respectively. Then switch to the project of your project and use r.proj and v.proj to reproject data from the temporary project to your project. This approach is necessary for formats which are not supported by r.import and v.import modules. Modules r.proj and v.proj can be also used for bringing raster and vector maps from one project to another.

Modules r.in.gdal and v.in.ogr check whether the CRS of the imported data matches the project's CRS. Sometimes the CRS of imported data is not specified correctly or is missing and therefore import fails. If you know that the actual CRS matches the project's CRS, it is appropriate to use r.in.gdal's or v.in.ogr's -o flag to overwrite the projection check and import the data as they are.

If you zoom to raster or vector in GRASS GUI and it does not fit with the rest of the data, it means that it was imported with wrong projection information (or with the -o flag when the coordinates in fact don't match). You can use r.info and v.info to get the information about the extents of (already imported) rasters and vectors.

Importing CSV and other ASCII data

There are many formats of plain text files. In the context of GIS we usually talk about ASCII formats and CSV files. CSV files usually hold only coordinates and sometimes attributes of points. These files usually don't have CRS information attached to them, so we must be very careful and import the data only if the coordinates are in the CRS of the project we are using.

Let's create a CSV file called points.txt using a text editor (Notepad++, TextEdit, MS Notepad), for example:

637803.6,223804.7
641835.5,223761.2
643056.0,217419.0

The coordinates we entered are in EPSG:3358 and we assume that the GRASS project is using this CRS as well. This file can be imported to GRASS GIS using:

v.in.ascii input=points.txt output=test_ascii separator=comma x=1 y=2

Notice, we have to specify the column number where the X and Y (optionally Z) coordinates are stored. In this example, X coordinates are in the first column Y in the second one. Don't forget to specify correct column delimiter.

If the data are not in the CRS we are using, create a new project with matching CRS, import the data and use v.proj as described above.

Importing lidar point clouds

Lidar point clouds can be imported in two ways: as raster maps using binning or as vector points. However, one must explore the dataset first.

In command line, we can check the projection information and other metadata about a LAS file using lasinfo tool:

lasinfo tile_0793_016_spm.las

r.in.lidar module can be used to scan the spatial extent of the dataset:

r.in.lidar input=tile_0793_016_spm.las -s

Binning

Before creating the actual raster with elevation, we need to decide the extent and the resolution we will use for the binning. We can use r.in.lidar module for that by setting the resolution directly and using a -e flag to use dataset extent instead of taking it from the computational region. We are interested in the density of points, so we use method=n:

r.in.lidar input=tile_0793_016_spm.las output=tile_0793_016_n method=n -e resolution=2

After determining the optimal resolution for binning and the desired area, we can use g.region to set the computational region. r.in.lidar without the additional parameters above will create a raster map from points using binning with resolution and extent taken from the computational region:

r.in.lidar input=tile_0793_016_spm.las output=tile_0793_016

Interpolation

When the result of binning contains a lot of NULL cells or when it is not smooth enough for further analysis, we can import the point cloud as vector points and interpolate a raster.

Supposing that we already determined the desired extent and resolution (using r.in.lidar as described above) we can use v.in.lidar lidar for import (and using class filter to get only ground points):

v.in.lidar input=tile_0793_016_spm.las output=tile_0793_016 class=2 -r -t -b

This import only the points of class 2 (ground) in the current computational region without the attribute table and building the topology. Then we follow with interpolation using, e.g. v.surf.rst module:

v.surf.rst input=tile_0793_016 elevation=tile_0793_016_elevation slope=tile_0793_016_slope aspect=tile_0793_016_aspect npmin=100 tension=20 smooth=1

Importing data in different CRS

In case the CRS of the file doesn't match the CRS used in the GRASS project, reprojection can be done before importing using las2las tool from libLAS.

The following example command is for reprojecting tiles in NAD83/North Carolina in feet (EPSG:2264) into NAD83/North Carolina in meters (EPSG:3358):

las2las --a_srs=EPSG:2264 --t_srs=EPSG:3358 -i input_spf.las -o output_spm.las

Importing data in LAS version 1.4 or newer

The LAS version 1.4 is not backwards compatible for readers expecting LAS 1.2. Unfortunately, libLAS supports only 1.2 and not 1.4. Fortunately, PDAL can convert to the version 1.2 using the translate tool:

pdal translate --input=input_v14.las --writers.las.minor_version=2 --output=output_v12.las

Importing data with broken projection information

Modules r.in.lidar and v.in.lidar check whether the CRS of the imported data matches the project's CRS. Sometimes the CRS of imported data is not specified correctly or is missing and therefore import fails. If you know that the actual CRS matches the project's CRS, it is appropriate to use r.in.lidar's or v.in.lidar's -o flag to overwrite the projection check and import the data as they are.

r.in.lidar input=tile_0793_016_spm.las -s -o

Transferring GRASS GIS data between two computers

If two GRASS GIS users want to exchange data, they can use GRASS GIS native exchange format – packed map. A vector or raster map can be exported from a GRASS project in this format using v.pack or r.pack respectively. This format preserves everything for a map in a way as it is stored in a GRASS Database. Projection of the source and target GRASS projects must be the same.

If GRASS GIS users wish to exchange GRASS Mapsets, they can do so as long as the source and target GRASS projects have the same projection. The PERMANENT Mapset should not be usually exchanged as it is a crucial part of the given project. Projects can be easily transferred in between GRASS Database directories on different computers as they carry all data and projection information within them and the storage format used in the background is platform independent. Projects as well as whole GRASS Databases can be copied and moved in the same way as any other directories on the computer.

NCSU GIS/MEA582:
Geospatial Modeling and Analysis