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 <[email protected]> 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 <[email protected]> > *To:* [email protected] > *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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
