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 May 5 '15 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. – Tomasz Warkocki May 6 '15 at 7:50

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? – Tomasz Warkocki May 6 '15 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 May 6 '15 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. – Tomasz Warkocki May 7 '15 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? – Tomasz Warkocki May 3 '15 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. – fluidmotion May 4 '15 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. – fluidmotion May 4 '15 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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