Problem with contour lines thickness in bigger zoom levels

Question

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

Answer 1

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)

  or

• 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.

Answer 2

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