3

I have tried searching on here for my issues, read many threads, but to no avail.

Essentially, I am trying to convert a line feature to a raster so that I can run proximity on it - because I want to use it in the raster calculator to find areas that are both X elevation and X distance from a road. I have buffered the line (road) by 200m, and want to convert the buffered layer to a raster.

Whichever way I run the converter, I get the same non-existent layer with min/max 1.79769e+ 308 values.

Any suggestions?

v3.4.4

Processing algorithm…
Algorithm 'Rasterize (vector to raster)' starting…
Input parameters:
{ 'BURN' : 1, 'DATA_TYPE' : 5, 'EXTENT' : '-16.95314021128497,-16.0864476950926,27.984934352626247,28.611619710488423 [EPSG:4326]', 'FIELD' : None, 'HEIGHT' : 1000, 'INIT' : None, 'INPUT' : 'C:/Users/Ben/Documents/University/EnvGIS/qgis/buffer_road.gpkg|layername=buffer_road', 'INVERT' : False, 'NODATA' : 0, 'OPTIONS' : '', 'OUTPUT' : 'C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif', 'UNITS' : 0, 'WIDTH' : 1000 }

GDAL command:
gdal_rasterize -l buffer_road -burn 1.0 -ts 1000.0 1000.0 -a_nodata 0.0 -te -16.95314021128497 27.984934352626247 -16.0864476950926 28.611619710488423 -ot Float32 -of GTiff C:/Users/Ben/Documents/University/EnvGIS/qgis/buffer_road.gpkg C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif
GDAL command output:
0...10...20...30...40...50...60...70...80...90...100 - done.

Execution completed in 0.30 seconds
Results:
{'OUTPUT': <QgsProcessingOutputLayerDefinition {'sink':C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif, 'createOptions': {'fileEncoding': 'System'}}>}

Loading resulting layers
Algorithm 'Rasterize (vector to raster)' finished

Raster information log

Processing algorithm…
Algorithm 'Raster information' starting…
Input parameters:
{ 'INPUT' : 'C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif', 'MIN_MAX' : False, 'NOGCP' : False, 'NO_METADATA' : False, 'OUTPUT' : 'C:/Users/Ben/AppData/Local/Temp/processing_068aa7c8382d44f4974580e307eb6f9f/630ed4178e7946888b29335bca0f80b6/OUTPUT.html', 'STATS' : True }

GDAL command:
gdalinfo -stats C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif
GDAL command output:
ERROR 1: C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif, band 1: Failed to compute statistics, no valid pixels found in sampling.

Driver: GTiff/GeoTIFF

Files: C:/Users/Ben/Documents/University/EnvGIS/qgis/raster_road_w_buffer.tif

Size is 1000, 1000

Coordinate System is:

PROJCS["WGS 84 / UTM zone 28N",

GEOGCS["WGS 84",

DATUM["WGS_1984",

SPHEROID["WGS 84",6378137,298.257223563,

AUTHORITY["EPSG","7030"]],

AUTHORITY["EPSG","6326"]],

PRIMEM["Greenwich",0,

AUTHORITY["EPSG","8901"]],

UNIT["degree",0.0174532925199433,

AUTHORITY["EPSG","9122"]],

AUTHORITY["EPSG","4326"]],

PROJECTION["Transverse_Mercator"],

PARAMETER["latitude_of_origin",0],

PARAMETER["central_meridian",-15],

PARAMETER["scale_factor",0.9996],

PARAMETER["false_easting",500000],

PARAMETER["false_northing",0],

UNIT["metre",1,

AUTHORITY["EPSG","9001"]],

AXIS["Easting",EAST],

AXIS["Northing",NORTH],

AUTHORITY["EPSG","32628"]]

Origin = (-16.953140211284971,28.611619710488423)

Pixel Size = (0.000866692516192,-0.000626685357862)

Metadata:

AREA_OR_POINT=Area

Image Structure Metadata:

INTERLEAVE=BAND

Corner Coordinates:

Upper Left ( -16.9531402, 28.6116197) ( 19d29'20.02"W, 0d 0' 0.93"N)

Lower Left ( -16.9531402, 27.9849344) ( 19d29'20.02"W, 0d 0' 0.91"N)

Upper Right ( -16.0864477, 28.6116197) ( 19d29'20.00"W, 0d 0' 0.93"N)

Lower Right ( -16.0864477, 27.9849344) ( 19d29'20.00"W, 0d 0' 0.91"N)

Center ( -16.5197940, 28.2982770) ( 19d29'20.01"W, 0d 0' 0.92"N)

Band 1 Block=1000x2 Type=Float32, ColorInterp=Gray

NoData Value=0

Metadata:

STATISTICS_VALID_PERCENT=0

Execution completed in 0.16 seconds
Results:
{'OUTPUT': 'C:/Users/Ben/AppData/Local/Temp/processing_068aa7c8382d44f4974580e307eb6f9f/630ed4178e7946888b29335bca0f80b6/OUTPUT.html'}

Loading resulting layers
Algorithm 'Raster information' finished
HTML output has been generated by this algorithm.
Open the results dialog to check it.
12
  • The output raster extent must include the extension of the input vector layer. If you burn a fixed value, do not assign that value for nodata. Do some of these tips solve your problem? Feb 3, 2019 at 0:15
  • Thanks for your reply Gabriel. I have been setting the output extent to a layer that definitely contains the input vector (in my case, the island outline is set as the extent for the roads on the island). I have been trying to set the fixed value to 1 and the nodata value to 0, but no luck.
    – BSiggery
    Feb 3, 2019 at 0:18
  • Please edit your question to include the output log of the Rasterize tool as preformatted text in the body of your question. Feb 3, 2019 at 0:20
  • Also specify which version of QGIS 3.4 you use. Feb 3, 2019 at 0:23
  • 1
    Ran completely from scratch this morning, removing any spaces in file path, ensuring burn values set to 1 and 0, nothing burning from a field. See original post for log. I have also now put the log for raster information,
    – BSiggery
    Feb 3, 2019 at 8:47

2 Answers 2

2

The problem is in the definition of the extents of the output raster.

When using an input layer with a Coordinate Reference System, but defining the extension of the output raster through a layer with a different CRS, the Rasterize tool creates a raster with the CRS of the input layer, but with the coordinates of its extents referred to the other system.

As a result, nothing that was in the input layer is found in those coordinates and the output raster contains only nodata values.

The solution is to use both layers defined under the same CRS (reprojecting some of them), when it is intended to Raterize a layer with the extents defined by another layer.

5
  • I still get this problem when I use the extents of the layer I'm rasterising, or if I drag extents manually on the canvas. If I use georeferenced units I get attempt to create 0x0 dataset is illegal error, if I use pixels it gets created but with no valid cells.
    – dez93_2000
    Nov 27, 2019 at 4:47
  • @dez93_2000 Are you assigning values greater than zero to vertical and horizontal resolution? Nov 27, 2019 at 4:54
  • yes - should I NOT be? Playing around with it, it seems res values are inversely proportional to number of rows/columns created, which makes sense.
    – dez93_2000
    Nov 27, 2019 at 5:12
  • @dez93_2000 They are the resolution. In pixels, is directly proportional (in fact, equivalent) to the number of rows and columns. In units, inversely proportional (divide the extent over the units resolution to obtain the number of rows or columns). Nov 27, 2019 at 5:17
  • Yep, that's what I figured. I've played around with different values which create correspondingly different sized outputs in terms of row/column numbers (if using pixels), but they're statistically not valid. Not to worry, I remembered I gave up on this in QGis before and did it in R. Thanks!
    – dez93_2000
    Nov 27, 2019 at 5:21
0

It could be to do with the size of the space you're using to save the layers in. Not sure about this, but the same thing was happening to me and it turned out my drive was full. I deleted some things and it worked, but I also made sure my CRS info was the same for each layer etc and went through that very carefully.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.