I have a map in which I am defining the sizes of various features in map units. When I come to generate a pdf of the map, using the Print Composer, the map itself is fine, but when I include a legend then the symbol elements of the lines are represented at a totally inappropriate size (e.g. a 'Main road' symbol swamps the whole legend).

I think it is the use of map units that is the cause of the problem as switching the line width to absolute units (e.g. mm) on the original map produces an appropriately sized line symbol in the legend. It seems like the legend that appears in the Print Composer is directly reflecting the way it appears in the Layer TOC - where, again, using map units produces oversized symbols relative to the map. However this is only true for lines. Point symbols rendered in map units appear exactly as I would expect in the Print Composer legend.

I would be very grateful if anyone can enlighten me as to whether this is a known problem, my misunderstanding of something, or there is a solution/setting/trick that I have missed.

I'm using QGIS 1.7.4 on Mac OSX 10.6.

Thanks for any help.



Phil, I too have struggled with this, but have a workable solution to use map units and a display a reasonable legend, until independent setting of legend line thickness is supported. You are using 1.7.4, so you can utilize this workaround, as it leverages the new symbology options.

Let's assume your map is in UTM (map units of meter) and you want your 'Roads' layer classified by type with a different symbol thickness in map units for relative display purposes (i.e. not real-world accuracy):

Road > Width
Highway > 20 m
Secondary > 10 m
Gravel > 5 m

For your Roads layer, you will need to make a new column in your data source of type real, with an appropriate size and precision for your use, lets call it 'ledgscale'. Edit your data and input the road width (in meters, as above) in the ledgscale column. There are many tools in QGIS for auto-updating your data relative to the road type column (Field Calculator, SQL, etc.).

The ledgscale column will scale your road type symbol's base width in map units.

Open the layer properties dialog for the Roads layer and go to Style, then choose to use New Symbology. Choose Categorized for symbol method, and set the Column to whatever your road type column is. Before clicking the Classify button, change the default symbol. Set the symbol's Unit to Map Units and the width to 1 (i.e. 1 meter, in this case). This will be used as a basis for the size in the legend later, and for scaling to your desired map units width for map features.

Click Classify to generate your road type symbols. Click the Advanced button and choose ledgscale under the Size scale field sub menu. This will scale your base symbol width by the ledgscale integer for each feature:

Highway -> (symbol width of n map units) * (ledgscale of 20) = output of legend at (n * 0.3 mm) and map feature at n * 20 map units width
Highway -> (1 meter) * 20 = legend of 0.3 mm and map feature of 20 meters

The 0.3 mm seems to be the default size for legend line widths (and other composer lines, like frames). This seems to be similar to the default of 0.26 mm for symbol lines.

You can do this technique with the other symbol methods, i.e. Single, Graduated, and Rule-Based. Rule-Based is the most flexible, albeit complicated.

Caveats: Changing the symbol's width beyond/below 1 (say to increase/decrease the size of the line in the legend) will affect that symbol's width on the map as well. You will also have to adjust the ledgscale number for all features that use that symbol.

This wacky workaround is how I have found to make it work, but coding QGIS to support fully independent control over legend line size is the correct solution.


  • dakcarto - many thanks for the ingenious workaround, and your clear explanation of it. Much appreciated. I'm glad it wasn't just me missing something, but it certainly is something it would be great to have fixed. Just defaulting to the line sizes in the legend being the same as on the map (in absolute terms in the Print Composer layout) would be good. The only limitation I found with the workaround was that it doesn't work for lines that are polygon borders. I guess breaking the polygon into line segments would be necessary for that. Anyway, many thanks. Phil
    – phw
    Apr 5 '12 at 22:02
  • @phil - The more I think about, this is a bug. Since the legend is linked to a composer map item of known scale, the legend item whose symbol is defined by map units could be scaled to match the symbols of features on the map item. I'll submit a issue ticket for this at hub.qgis.org.
    – dakcarto
    Apr 5 '12 at 22:09
  • I would agree, I think it is a behaviour that would never be what one wanted, so is probably not intended. The fact that with polygon borders it cannot be worked around with the method above is also an issue. The only solution I found to that was to generate the map using map units, add it to Print Composer, then go back change the border sizes to the correct size in mm, go back to Composer, add the legend - which now has the correct line widths - being exceedingly careful not to refresh the map! Not elegant! If you are happy to raise the issue, that would be great - thanks. Phil
    – phw
    Apr 6 '12 at 8:23

I've run into the same issue (with QGIS 1.8.0 on Mac). In short, my workaround is to generate the legend in the composer using millimetres, prevent the corresponding legend item from being updated, and then go back to map units on the layer itself.

Here's the longer version:

  1. First, set the feature symbol to use millimetres, not map units
  2. In the composer, add the legend and item for the corresponding layer, and configure as you see fit
  3. Uncheck Auto Update in the Item Properties > Legend Items
  4. Go back to the Style tab of the layer and configure the symbol using map units for correct display

Do not check Auto Update! Do not click the Update button for this legend item in the Print Composer!

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.