As Brent mentioned before, this is a easy task for GMT
# Find the grid limits
minmax 001-1.xyz -I5
-R568350/594035/6624700/6678645
#Convert to netCDF
xyz2grd -R568350/594035/6624700/6678645 -I5 -G001-1.grd 001-1.xyz
It was also mentioned that:
"The convention in the offshore sector is to deliver bathymetric data as
single 'gridded' .XYZ ASCII file"
well, maybe so but I'm not so aware of it. What we use to use are grids
directly or otherwise converted to x,y,z but stored in binary file,
either for file size and to avoid truncations in decimal places (a 5 m
grid spacing would need >= 6 decimal places when in geographics).
Joaquim
Le dimanche 08 juin 2014 15:04:31, Sam Franklin a écrit :
Even - okay thanks for taking a look, I'll check out the 2.0dev version as
you mentioned.
Sam,
I meant that the 2.0dev has some improvements, but they are not sufficient to
read that file.
Even
Cheers
S
On 7 June 2014 21:59, Even Rouault<[email protected]> wrote:
Le samedi 07 juin 2014 22:31:09, Sam Franklin a écrit :
Hey Even - me again on this xyz sorting issue.
I've got a new xyz file that it is not recognised by gdal even after
using
the sort command you provided earlier in the thread.
The problem xyz is here |
https://dl.dropboxusercontent.com/u/4086367/001-1.xyz.zip
The error is:
ERROR 1: Ungridded dataset: At line 363, X is 568509.090000, where as
568514.090000 was expected (1)
gdalinfo failed - unable to open '001-1.xyz'.
GDAL seems to fail at the start of a new row of data?
I've tried various descend/ascend combinations of the columns = no joy.
I'm running GDAL 1.11.0 on OSX 10.9.3.
Any ideas? Thanks again in advance for any help! Very much
appreciated.
The development version 2.0dev has improvements over 1.11 that would help
a bit, but this file would still require additional developments since
the spacing between horizontal or vertical coordinates isn't constant
due to rounding to 2 decimal figures. Some tolerance should be added to
the driver to
support it.
Cheers
Sam
On 27 May 2014 14:09, Sam Franklin<[email protected]>
wrote:
Hi Even. Great, that worked for me too when sorting on both columns.
Really appreciate you help.
Sam
On 27 May 2014 01:31, Even Rouault<[email protected]>
wrote:
Le mardi 27 mai 2014 00:06:33, Sam Franklin a écrit :
Hey Even - great tip. The sort command you suggested worked well
with
that
xyz dataset.
However, I've found a further dataset that does not work with gdal
even after the sort. This is the error:
mbp-sf:data08 samfranklin$ gdal_translate data08-02-sorted.xyz
data08-02.tif
Input file size is 4371, 11210
0...10...20...30...40.ERROR 1: At line 1100207, found 48162.000000
instead
of 48164.000000 for nBlockYOff = 4951ERROR 1:
data08-02-sorted.xyz,
band 1:
IReadBlock failed at X offset 0, Y offset 4951
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset
4951
See screenshot below, the data is arranged into three 'strips'.
See
dropbox
link to the data |
https://dl.dropboxusercontent.com/u/4086367/data08-02.xyz.zip
Any workaround you can think of?
Probably an issue with just sorting on column 2. I didn't have the
same
error
as you, but anyway you should try :
sort -nk 2 -nk 1 data08-02.xyz> data08-02-sorted.xyz
with that I manage to translate the file.
--
Geospatial professional services
http://even.rouault.free.fr/services.html
--
Geospatial professional services
http://even.rouault.free.fr/services.html
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
