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

[Sam Franklin]

Hey Brent - Oh boy. I really appreciate the info.

GMT's xyz2grd looks very promising indeed |
http://gmt.soest.hawaii.edu/doc/latest/xyz2grd.html

I'll check out the other links too.

Embarrassingly, I've been banging my head against this brick wall for years
:-)

Many thanks Brent - total life saver!



On 24 May 2014 22:25, Brent Wood <pcreso at pcreso.com> wrote:

> 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 geotiffs directly from the grid data, the combination of GMT &
> GDAL is 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/141e5897/attachment.html>