Bug report #15535
Bug converting shapegrid to ASCII Grid raster
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Processing/GDAL | ||
| Affected QGIS version: | 2.14.4 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 23458 |
Description
I am currently in my first year of Phd, and I am working on Species Distribution Models, with the software "MaxEnt".
This software accept only the .asc format for my environnemental layers but when I convert a shapegrid to a .asc format raster with qgis, the output file is unreadable... It is filled by symbols.
More details:
I have a shape of crops (for example cereals). I intersect this shape with a shapegrid (200m x 200m) to obtain the area of the crop in each of the cells of my shapegrid and I want to transform this shapegrid to a .asc format raster because I have to enter it into the software "MaxEnt" which accept only this format.
But when I convert my shapegrid from .shp to .asc (the ASCII grid format was well selected in the rolling menu of the output formats) with the tool "rasterize", the output file is unreadable because it contains only symbols whereas it should contain the value of my pixels.
And when I go to metadata it is written "GDAL provider GTiff GeoTIFF" in the "Pilote" section.
So the solution I found is to convert my shapegrid to .geotiff, open the geotiff file under SAGA GIS, and convert it to .asc. The output file is readable and correct but it is very heavy and time consuming.
The issue seems to be the same in QGIS Valmiera as in Essen (2.14)
History
#1
Updated by Even Rouault about 8 years ago
I have had a look at that. The issue is that in GDALTools the rasterizer offers a save box that list all GDAL supported rasters. But only those that have update mode support (DCAP_CREATE) should be listed, and AAIGRID is not one of those. Furthermore if you select a format like ERDAS Imagine, the "-of HFA" flag will not be set, so a GeoTIFF will be created.
#2
Updated by Giovanni Manghi almost 8 years ago
- Resolution set to up/downstream
- Status changed from Open to Closed
- Category set to Processing/GDAL
@rouault
Maybe I missing something (maybe a gdal utilities parameter), so feel free to reopen.
I have lately supported some ex colleague preparing input files for Landscape Analysis packages like the here cited maxent, circuitscape, fragstat, gflow and others.
They all need inputs as .asc files.
With a pure gdal utilities workflow (rasterize + translate) the obtained .asc files are usually a) not accepted by the above packages or b) work but leading to wrong results. Creating the .asc within other packages (saga, arcgis) usually lead to files are accepted by the cited software.
Can provide sample data if necessary.
PS
gdal tools was removed in favor of the equivalent Processing gdal based tools. Yet formats that are not writable are still listed, like .asc in gdal_rasterize. But this is another issue.
#3
Updated by Giovanni Manghi almost 8 years ago
- File regflow.zip added
Attached sample data:
there is a shape rasterized with a proprietary sw gis (patch.asc) that works as expected in the cited landscape analysis software.
There is also a rasterized version (patches_asc_translate.asc) obtained with gdal (rasterize + translate), the result does not work in the cited landscape analysis software.