Bug writing GSAG formatted files

[davisnn]

I have been using GDAL to convert Viewfinder DEM data (HGT format) to the GSAG format. I found that for many of these files there are issues with the GSAG output.

All tests were carried out using GDAL 2.2.0 that was installed using the conda package manager from the Conda Forge respository on an Ubuntu Linux system.

The data can be downloaded from ​http://viewfinderpanoramas.org/dem3/K33.zip. I have attached a Jupyter Notebook that runs through the translation, and produces some of the results of my tests.

In summary, the conversion of the file to GeoTiff always produces differences of 0, while converting to GSAG there are often large differences. I found that if I clipped the domain to a smaller region, in the case of the file N41E013.hgt, 385 pixels starting from pixel 200, I would get no differences, but if I included a 386th pixel the differences would show up. This was not true however if I tried starting from pixel 100, as when starting there both 385 and 386 points would work.

Please let me know if there is other information that I can provide, or if there is a systematic way that I can help to test this.

[davisnn]

IPython Notebook showing steps I tried to test the conversion

[Even Rouault]

In 39764:

GSAG: fix reading issue that could cause a spurious 0 value to be read and shift all following values (fixes #6992)

[Even Rouault]

In 39765:

GSAG: fix reading issue that could cause a spurious 0 value to be read and shift all following values (fixes #6992)

[Even Rouault]

In 39766:

GSAG: fix reading issue that could cause a spurious 0 value to be read and shift all following values (fixes #6992)

[Even Rouault]

Note: the issue probably applies to even older versions.

[Even Rouault]

Note: the issue was on the read side, not the write side

[davisnn]

Great, thank you for the fix, and good to know that it was only on the read side.