I'm a beginner user of GDAL tools. I'd like to rasterize contour lines into Tiff file (for example such region: N47E006), everything works for quite small zoom levels e.g. 10... but the problem is with bigger zoom levels... contour lines are very "pixelised" and for mountains black contour lines covers almost whole Tiff image. Is there a way to create thinner contour lines for bigger zoom levels e.g. 15-18?

I'm using this for generating contour lines (10m):

gdal_contour -a elev -i 10 input.tif contours.shp 

this for rasterization:

gdal_rasterize -b 1 -b 2 -b 3 -burn 0 -burn 0 -burn 0 -l contours contours.shp input.tif

and this for cutting into tiles:

gdal2tiles.py -z 15-18 -n -e -w openlayers input.tif out_dir
  • Your input file for gdal_contour and your output file for gdal_rasterize are both called input.tif. Are you burning the contours into the original elevation data GeoTIFF file?
    – das-g
    Commented May 5, 2015 at 12:01
  • This is actually white image (I've skipped this steps in the question) with same size and geodata restored from original Tiff file... then I rasterize contours into this white image and turn white color into transparent in order to have only contour lines on transparent background. Commented May 6, 2015 at 7:50

2 Answers 2


Line widths are determined at the rasterization step

Other than lines in a vector image (e.g. SVG), lines in vector data do not have an inherent width. They are lines in a mathematical, not in a graphical sense. I assume that this is also the case for contours.shp, the output of the contour finding step with gdal_contour.

Thus line width is determined by the rasterization step.

(Tiling, when done after the rasterization like here, cannot know about the original vector data and thus cannot control the line widths. It will influence them though by raster image scaling, leading to the aliasing you describe.)

Controlling line width

As gdal_rasterize doesn't seem to feature any settings directly related to it except for -at (burning "all pixels touched by lines or polygons [...], not just those on the line render path"), I assume that it always uses a line width of one pixel.

So we cannot control line width directly.

But even if we could, setting it to sub-pixel values wouldn't do us much good: One cannot color half a pixel. And even if gdal_rasterize was clever and would do some antialiasing, mixing the original image color/value with the burn color/value, the raster image scaling in the following tiling step would still introduce the aliasing you describe.

Indirect control

I hope we can avoid that effect indirectly when taking away from the tiling step the need to up-scale at all by providing an image already in the correct pixel-per-cartographic-unit resolution to gdal2tiles.py. (As you probably work in Mercator projection, the cartographic unit will be neither meters nor degrees, but this doesn't have to concern us.)

Off course, if we just take the result from gdal_rasterize and scale it ourselves, we haven't won anything, as we'd introduce the aliasing ourselves. Rather, we have to burn the contours into a higher-resolution image right at the rasterization step.

Controlling resolution

I guess gdal_rasterize, when given an existing file as output file, will just modify values (colors) of affected pixels and will not change the size/resolution of that pre-existing image. Thus I don't think the -tr option suggested by fluidmotion or -ts option would have any effect. (I haven't tried, though.)

Thus I suggest you either

  • let gdal_rasterize generate the image, using the -tr or -ts option

    • (which might or might not re-create the geo-referencing needed for tiling)


  • scale the target file yourself before providing it to gdal_rasterize
    • (make sure to keep the geo-referencing consistant)

Choosing the right resolution

The area covered by a tile of zoom level N will be covered by 4 (2 x 2) tiles of zoom level N+1. So for each increment of the zoom-level you have to double the resolution for both, x and y direction.

  • Thanks a lot for your answer! About two possible solutions... I will try to pass valid resolutions to gdal_rasterize (tr, ts)...and will see. But how can I scale image for option two keeping geodata? Are the geodata same for source tiff and scaled one or should be adjusted? Commented May 6, 2015 at 11:42
  • I don't know how the georeferencing in TIFF is done. If it's stored as one geo-position (e.g. the center or a single corner) and the pixel-per-cartographic-unit resolution, it will have to be adapted. However, if it's the 4 geo-positions of all 4 corners, you should be able to keep it as-is.
    – das-g
    Commented May 6, 2015 at 12:25
  • Ok,so partial success with initial image of size: 11404x16880 (4 times bigger than source image). But still for me the question is what is default zoom level for source image. And what image dimensions should I use for each zoom level. Commented May 7, 2015 at 7:47

i'm not sure what the default resolution is for gdal_translate if none is given, but you might try specifying some resolution based on the zoom level you desire per the docs -

-tr xres yres :

(GDAL >= 1.8.0) Set target resolution. The values must be expressed in georeferenced units. Both must be positive values
  • Thx! But where can I find what resolutions should I use for specific zoom levels? The original Tiff has: 2851x4220px. And what does it mean georeferenced units? Commented May 3, 2015 at 21:12
  • hopefully i won't confuse things here- but i think normally you could determine the extent of the image (in georeferenced units - lets assume it's in meters and covers a 100,000 meters in both directions): 100,000/2851 = about 35 meter resolution (in the x-direction). I guess if the terrain is very steep, you would have a lot of contours - each 35 meters wide when rasterized, which would certainly black out a lot of the image. Commented May 4, 2015 at 1:18
  • so if you wanted a 10 meter resolution - i think you would enter that as an argument to gdal_rasterize. If your extent is large, this can significantly increase file size. Commented May 4, 2015 at 1:21

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.