[gdal-dev] Using GDAL with gridded XYZ that has no 'nodata' values?

[Brent Wood]

Hi 


Any reason for requiring a GDAL only system?

GMT & MB (MultiBeam) System (http://gmt.soest.hawaii.edu/ & http://www.ldeo.columbia.edu/res/pi/MB-System/ ) are Open Source tools built specifically for working with seabed & multibeam data.

GMT netCDF grids are supported by GDAL, & GMT can also create the greyscale geotiffsdirectly from the grid data, the combination of GMT & GDALis extremely powerful and effective.

The other Open Source tools I'd look at in this context, for a fully functional suite for such work, is Postgis, where the new pgraster functionality allows you to manage the gridded data (including large sets of geotiff imagery.

Of course, in the FOSS arena, there is also GRASS, which has some very powerful raster/DEM tools, but I find of limited value in the maritime arena, as well as OSSIM, both include command line tools you can script along with GDAL. And there are others, but in the maritime & multibeam Open Source space I suggest that GMT & MB System (ideally with GDAL) reign supreme :-)

Cheers,

   Brent Wood


________________________________
 From: Sam Franklin <mailinglist.samfranklin at gmail.com>
To: gdal-dev at lists.osgeo.org 
Sent: Sunday, May 25, 2014 7:45 AM
Subject: [gdal-dev] Using GDAL with gridded XYZ that has no 'nodata' values?
 


Greetings. This is my first post to this mailing list, so apologies if I commit a mailing-list faux-pas :)

I wonder if anyone can offer a suggestion, as I'm hoping I've missed something obvious.

I regularly receive bathymetric DEMs, acquired by acoustic multibeam echosounders (MBES) from offshore geophysical surveys that take the form of narrow corridors of survey or irregularly shaped areas.

My goal is to have a end-to-end open source/GDAL workflow that converts the bathymetric DEM to greyscale GEOTIFF which I can then use for further processing/analysis using GDAL/OGR.

The convention in the offshore sector is to deliver bathymetric data as single 'gridded' .XYZ ASCII file, where XY coordinate pairs are evenly spaced to form a grid and the textfile row order is spatially sequential.

However, crucially 'nodata' values are omitted from the XYZ.  I can only assume the reasoning was to reduce the file size on disc. This is an industry convention that will not change anytime soon.

gdal_translate obviously does not read these XYZ files as gdal throws an error due to the lack of true rectangular grid.  I've read the XYZ info http://www.gdal.org/frmt_xyz.html which is clear to me, no problem there.


I do not want to use gdal_grid on the XYZ as this will introduce a further interpolation step. The XYZs I receive are already cleansed and gridded by the surveyor which I don't wish to edit further.


So, I currently use a proprietary marine geophysical package which can directly read the gridded XYZ without nodata values.  Using this package, I can export to ESRI ASCII grid (.ASC) which I then use gdal_translate without issue for my further processing steps.

I'd like the freedom of a non-proprietary solution and the only thing I can think of is to write a python script to pre-process my XYZ into a format that gdal will accept.  I was thinking of calculating the XY bounding box of the data and output an XYZ that blends the original values and nodata values in the correct row order.

If anyone is interested, see below link to a zip of three separate examples, containing:
-- 'gridded' XYZ (without nodata values)
-- processed greyscale GEOTIFF (using proprietary package)
-- processed color-relief RGB GEOTIFF (using proprietary package)
https://dl.dropboxusercontent.com/u/4086367/gdal_translate_xyz_examples.zip
All data in these examples are referenced to SRS EPSG:27700.

If I've missed anything obvious, or if anyone has any thoughts of how I can achieve my goal using GDAL or other, or comment on my proposed solution, that would be greatly appreciated.

Thanks in advance.
Sam
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140524/2b68ad5a/attachment.html>