<div dir="ltr">Hey Even - well that's embarrassing, it looks like gdal 1.11.0 solves the problem for those three xyz files that I sent through! Great work, thanks!<div><br></div><div>However, I've found an example that fails to open here <a href="https://dl.dropboxusercontent.com/u/4086367/gdal_translate_xyz_data04-02.zip">https://dl.dropboxusercontent.com/u/4086367/gdal_translate_xyz_data04-02.zip</a></div>
<div><br></div><div>Using gdal 1.11.0 on osx 10.9.3, I receive the following error:</div><div>







<p class="">$ gdalinfo data04-02.xyz <br>ERROR 1: Ungridded dataset: At line 18, X is 516085.000000, where as 516100.000000 was expected (1)<br>gdalinfo failed - unable to open 'data04-02.xyz'.</p></div><div>I doubt you remember - I chatted to you about this problem at FOSS4G, sorry it's taken about 9 months to contact you!</div>
<div><br></div><div>Thanks in advance.</div><div>S</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 May 2014 23:43, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le samedi 24 mai 2014 21:45:45, Sam Franklin a écrit :<br>
<div><div class="h5">> Greetings. This is my first post to this mailing list, so apologies if I<br>
> commit a mailing-list faux-pas :)<br>
><br>
> I wonder if anyone can offer a suggestion, as I'm hoping I've missed<br>
> something obvious.<br>
><br>
> I regularly receive bathymetric DEMs, acquired by acoustic multibeam<br>
> echosounders (MBES) from offshore geophysical surveys that take the form of<br>
> narrow corridors of survey or irregularly shaped areas.<br>
><br>
> My goal is to have a end-to-end open source/GDAL workflow that converts the<br>
> bathymetric DEM to greyscale GEOTIFF which I can then use for further<br>
> processing/analysis using GDAL/OGR.<br>
><br>
> The convention in the offshore sector is to deliver bathymetric data as<br>
> single 'gridded' .XYZ ASCII file, where XY coordinate pairs are evenly<br>
> spaced to form a grid and the textfile row order is spatially sequential.<br>
><br>
> However, crucially 'nodata' values are omitted from the XYZ.  I can only<br>
> assume the reasoning was to reduce the file size on disc. This is an<br>
> industry convention that will not change anytime soon.<br>
><br>
> gdal_translate obviously does not read these XYZ files as gdal throws an<br>
> error due to the lack of true rectangular grid.  I've read the XYZ info<br>
> <a href="http://www.gdal.org/frmt_xyz.html" target="_blank">http://www.gdal.org/frmt_xyz.html</a> which is clear to me, no problem there.<br>
><br>
> I do not want to use gdal_grid on the XYZ as this will introduce a further<br>
> interpolation step. The XYZs I receive are already cleansed and gridded by<br>
> the surveyor which I don't wish to edit further.<br>
><br>
> So, I currently use a proprietary marine geophysical package which can<br>
> directly read the gridded XYZ without nodata values.  Using this package, I<br>
> can export to ESRI ASCII grid (.ASC) which I then use gdal_translate<br>
> without issue for my further processing steps.<br>
><br>
> I'd like the freedom of a non-proprietary solution and the only thing I can<br>
> think of is to write a python script to pre-process my XYZ into a format<br>
> that gdal will accept.  I was thinking of calculating the XY bounding box<br>
> of the data and output an XYZ that blends the original values and nodata<br>
> values in the correct row order.<br>
><br>
> If anyone is interested, see below link to a zip of three separate<br>
> examples, containing:<br>
> -- 'gridded' XYZ (without nodata values)<br>
> -- processed greyscale GEOTIFF (using proprietary package)<br>
> -- processed color-relief RGB GEOTIFF (using proprietary package)<br>
> <a href="https://dl.dropboxusercontent.com/u/4086367/gdal_translate_xyz_examples.zip" target="_blank">https://dl.dropboxusercontent.com/u/4086367/gdal_translate_xyz_examples.zip</a><br>
> All data in these examples are referenced to SRS EPSG:27700.<br>
><br>
> If I've missed anything obvious, or if anyone has any thoughts of how I can<br>
> achieve my goal using GDAL or other, or comment on my proposed solution,<br>
> that would be greatly appreciated.<br>
<br>
</div></div>What would be interesting is a link to a XYZ file that fails to be opened. In<br>
GDAL 1.11, I've improved the driver to be able to handle lines with missing<br>
values at their start and end. It might be possible to improve it again to<br>
deal with nodata values that would be at any place within lines. If the whole<br>
file is regularly gridded of course.<br>
<br>
><br>
> Thanks in advance.<br>
> Sam<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</font></span></blockquote></div><br></div>