Import XYZ: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
(new)
 
mNo edit summary
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Import XYZ DEM data ==
== Import Gridded XYZ DEM data ==


There are a couple of ways to import regular DEM (elevation) data in XYZ ASCII format:
There are a couple of ways to import regular DEM (elevation) data in gridded XYZ ASCII format:
* use {{cmd|v.in.ascii}}, then  {{cmd|r.to.vect}}
* use {{cmd|v.in.ascii}}, then  {{cmd|v.to.rast}}
* use {{cmd|r.in.xyz}} along with {{cmd|g.region}}
* use {{cmd|r.in.xyz}} along with {{cmd|g.region}}


=== Hint if there are multiple white spaces as separator ===
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. {{cmd|v.surf.rst}}) or raster resampling (e.g. {{cmd|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 {{cmd|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.


Often one comes across ASCII tables formatted in unfortunate ways, e.g. like this:
=== Import with r.in.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
  ...


Above mentioned GRASS commands refuse to import directly from that since they require single (and not replicated) field separators.
'''Example:''' We want to import a XYZ ASCII file "VTL2733.XYZ". First we look at the structure of the file:


'''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.
  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
  ...


'''Example:''' We assume to import the XYZ ASCII file VTL2733.XYZ which shows above mentioned structure (which also indicates a 25m raster size):
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):
* First scan the map extent in human readable way (reduce white space on the fly, read from standard-input):
  cat VTL2733.XYZ | tr -s ' ' ' ' | r.in.xyz -s in=- fs=space out=test
  cat VTL2733.XYZ| r.in.xyz -s in=- fs=space out=test
  Range:    min        max
  Range:    min        max
  x: 617000.000000 619250.000000
  x: 617000.000000 619250.000000
Line 27: Line 28:
  z:  149.160000  162.150000
  z:  149.160000  162.150000
   
   
# set region, get from scanning the file again, now in machine-readable form (eval and -g flag):
* set region, get from scanning the file again, now in machine-readable form
  eval `cat VTL2733.XYZ | tr -s ' ' ' ' | r.in.xyz -s -g in=- fs=space out=test`
# (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
  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:
* 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
  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
* verify that the number of rows in the ASCII file corresponds to the number of cells in enlarged region
  wc -l VTL2733.XYZ
  wc -l VTL2733.XYZ
   
   
# finally import as raster map:
* finally import as raster map:
  cat VTL2733.XYZ | tr -s ' ' ' ' | r.in.xyz in=- fs=space out=vtl2733
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 {{cmd|r.out.gdal}}.
 
Inspecting the output of {{cmd|r.univar}} with r.in.xyz's <tt>method=n</tt> maps can be very useful for troubleshooting.
 
=== Import multiple files in one step into a single DEM ===
 
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 ==


Now you can analyse the map or export into a reasonable raster format (e.g., GeoTIFF) with {{cmd|r.out.gdal}}.
* [http://tldp.org/LDP/abs/html/textproc.html Text Processing Commands]
* [http://www.gnu.org/software/coreutils/manual/html_node/index.html GNU Coreutils]
* The [[LIDAR]] wiki page (discusses the import of ''sparse'' XYZ datasets)
* The [http://trac.osgeo.org/grass/browser/grass-addons/raster/r.in.xyz.auto r.in.xyz.auto] add-on script
* [https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&keywords=%7Er.in.xyz Open support tickets concerning r.in.xyz]


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

Latest revision as of 14:54, 20 December 2012

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.

Inspecting the output of r.univar with r.in.xyz's method=n maps can be very useful for troubleshooting.

Import multiple files in one step into a single DEM

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