Import XYZ: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(→‎Import with r.in.xyz: confirm with r.univar)
Line 84: Line 84:
* [http://tldp.org/LDP/abs/html/textproc.html Text Processing Commands]
* [http://tldp.org/LDP/abs/html/textproc.html Text Processing Commands]
* [http://www.gnu.org/software/coreutils/manual/html_node/index.html GNU Coreutils]
* [http://www.gnu.org/software/coreutils/manual/html_node/index.html GNU Coreutils]
* The [[LIDAR]] wiki page
* The [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.in.xyz.auto r.in.xyz.auto] add-on script


[[Category:Documentation]]
[[Category:Documentation]]
[[Category:FAQ]]
[[Category:FAQ]]

Revision as of 06:38, 13 May 2009

Import Gridded XYZ DEM data

There are a couple of ways to import regular DEM (elevation) data in gridded XYZ ASCII format:

By gridded it is meant that the data covers exactly one x,y,z data point per raster cell. For sparse data points or grids rotated or of a different resolution compared to the current raster region you should use one of the vector interpolation (e.g. v.surf.rst) or raster resampling (e.g. r.resamp.interp) modules to fill in any gaps after importing; and adjusting the region by half a cell outwards is not needed. For rotated grids, if possible, it is better to import them in their native projection then use r.proj to pull them into the target location. For grids of different resolution to the current raster region settings, if possible, it is better to import them in their native resolution.

Import with r.in.xyz

Example: We want to import a XYZ ASCII file "VTL2733.XYZ". First we look at the structure of the file:

 head -n 4 VTL2733.XYZ
 617000.0 148000.0 157.92
 617025.0 148000.0 157.82
 617050.0 148000.0 157.70
 617075.0 148000.0 157.60
 ...

It indicates a 25m raster cell size. To import, we run a few commands:

# First scan the map extent in human readable way (reduce white space on the
# fly, read from standard-input):
cat VTL2733.XYZ| r.in.xyz -s in=- fs=space out=test
Range:     min         max
x: 617000.000000 619250.000000
y: 148000.000000 151000.000000
z:  149.160000  162.150000

# set region, get from scanning the file again, now in machine-readable form
# (eval and -g flag):
eval `cat VTL2733.XYZ | r.in.xyz -s -g in=- fs=space out=test`
g.region n=$n s=$s w=$w e=$e res=25 -p

# enlarge region by half raster cell resolution to store values in cell-center:
g.region n=n+12.5 s=s-12.5 w=w-12.5 e=e+12.5 -p

# verify that the number of rows in the ASCII file corresponds to the number
# of cells in enlarged region
wc -l VTL2733.XYZ

# finally import as raster map:
cat VTL2733.XYZ | r.in.xyz in=- fs=space out=vtl2733

# and confirm that it all went cleanly, indicated by the absence of NULL cells:
r.univar vtl2733

Now you can analyse the imported elevation map or export into a reasonable raster format (e.g., GeoTIFF) with r.out.gdal.

Import multiple files in one step

Just amend above procedure to use wildcards. Change in above example all occurencies of

 cat VTL2733.XYZ

to

 cat *.XYZ

and use a more reasonable output name of course. That's all to import even thousands of files (tiled DEM) easily.

Hint if there are multiple white spaces as separator

Sometimes one comes across ASCII tables formatted in unfortunate ways, e.g. like this:

 617000.0 148000.0  157.92
 617025.0 148000.0  157.82
 617050.0 148000.0  157.70
 617075.0 148000.0  157.60
 ...

Above mentioned GRASS commands refuse to import directly this file since they require single (and not replicated) field separators.

Solution: On Unix-based systems, you can get rid of this on the fly and import the XYZ ASCII file to a raster map combining some text tools and GRASS commands. Just amend above procedure to use "tr".

Change

cat VTL2733.XYZ | r.in.xyz ...

to

cat VTL2733.XYZ | tr -s ' ' ' ' | r.in.xyz ...

Then proceed as above.

See also