<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Nyall,</p>
<p id="reply-intro">On 2019-01-24 11:09, Nyall Dawson wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">On Thu, 24 Jan 2019 at 17:59, Andreas Neumann <<a href="mailto:a.neumann@carto.net" rel="noreferrer">a.neumann@carto.net</a>> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br />Hi,<br /><br />I have two questions about saving rasters in QGIS 3.4:<br /><br />1.<br /><br />If I use "Right-klick layer" --> "Export" --> "Save AS" then I can't choose the ESRI ASCII Grid format described in "Settings" --> "Options" --> "GDAL" as "AAIGrid".<br /><br />Any idea why this format is not available for exporting rasters?</blockquote>
<br />The raster file writer only currently supports formats for which GDAL<br />has "creation" support, not "copy" . See<br /><a href="https://www.gdal.org/formats_list.html" target="_blank" rel="noopener noreferrer">https://www.gdal.org/formats_list.html</a> - AAIGrid supports copies only.<br /><br />This should be fixable with moderate effort -- we could create a<br />temporary dataset in a supported format (possibly even in memory for<br />smaller rasters), and then use GDAL's createcopy to write the result.<br />This would open up support for all raster drivers with copy but not<br />create support, including AAigrid, and a whole lot of other useful<br />formats too.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
</blockquote>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Thank you for the explanation. This is useful to know. It would be a nice thing to have "Save AS" also for formats that have no GDAL creation support.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">2.<br /><br />As an alternative I can use the "Raster" --> "Extraction" --> "Clip raster by extent". This works fine, but I can't set the number of decimal places after the comma.<br /><br />E.g. if I export a terrain model I would like to use 2-3 places after the decimal, not the full 8 digits, which is a false accuracy.</blockquote>
<br />I don't fully understand the issue here -- although the dialog is<br />showing that many decimal places, it doesn't affect the output file if<br />the extraneous digits are set to 0.<br /><br />Nyall</div>
</blockquote>
<p>Ok - I try to explain it better:</p>
<p>My data is originally coming from an ESRI ascii grid. It had been many hundred tiles of ascii grids which I merged into a single big GEOTIFF file. The original data had up to 3 digits after the decimal point for the terrain height (mm accuracy) per cell. After import to the Geotiff the data has now many more (useless) digits after the comma, because the number of the digits in the geotiff is now defined by the float32 data type I chose. When I export that data back to ESRI ascii grid I get 15! digits after the decimal point. I would like to round it back to 2 digits after the decimal point (cm accuracy).</p>
<p>In addition, the header in the resulting asciigrid has now many useless digits. It looks like this:</p>
<p>ncols 233<br />nrows 189<br />xllcorner 2681471.893245012965<br />yllcorner 1224297.020738559077<br />dx 0.999927877238<br />dy 1.000035130719<br />NODATA_value 0</p>
<p>Note that the resolution of the data is 1m. But in the export it comes out as dx 0.999927877238 - dy 1.000035130719</p>
<p>I wonder if I could force the resolution back to 1.0 (the original resolution).</p>
<p>So it is an issue of rounding/accuracy.</p>
<p>Thanks again,</p>
<p>Andreas</p>
<p><br /></p>
<p><br /></p>
<p><br /></p>
<p><br /></p>

</body></html>