I'm having trouble with the OpenLayers Plugin of Qgis and the map composer:

If I create an OSM-background layer and if I want to export this, the OSM-Layer looks perfectly all right in the normal qgis program window. But in the map composer and after export the layer has shifted relatively to my other shape layers (EPSG:32633 - WGS 84 / UTM zone 33N).

The second thing is that the output resolution of the exported osm-layer is very, very poor.

A really bad way of getting around this whole trouble would be to increase the screen resolution and make a screenshot of the map composition window of qgis. But I don't think this would be very professional. It also would cause a lot of pain :)

I'm using Qgis 1.8.0-Lisboa under Linux. The openlayers plugin is version 0.92.

coastlines shifted

  • 1
    Desputin, Did you ever find a solution to printing high quality OSM print resolution?
    – C_K
    Commented Apr 18, 2013 at 17:10
  • 1
    The OpenLayers plugin does NOT SUPPORT printing. Use QuickMapServices instead gis.stackexchange.com/questions/20191/…
    – underdark
    Commented May 30, 2016 at 18:53
  • Having this same problem with QuickMapServices plugin and making the map the size of the page does not solve it. Any other suggestions?
    – TTome
    Commented Feb 19, 2019 at 0:28
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
    – whyzar
    Commented Feb 20, 2019 at 14:52

7 Answers 7


It is a common bug, and there are many threads that deal with this.

A solution is to make your map element/object fit the map composer.



  • Thank you, but this is really annoying. Is there any walk around? In my case, the map looks good in map composer, but the exported images are wrong.
    – user2821
    Commented May 18, 2015 at 18:22
  • 1
    Once the map div fits 100% your map composer (this is the main issu if you have a shift), you can add white shapes (ie rectangles) on all sides of the map composer. Hope that helps Commented May 19, 2015 at 9:42
  • 1
    I was having the same problem and changing the map canvas the size of the page worked. I'm using QGis 2.8.1 in Win7
    – Daniel
    Commented May 22, 2015 at 13:46
  • A similar and easier workaround for me was to choose the Crop to Content option when exporting to an image.
    – amball
    Commented Nov 25, 2017 at 20:21

Late Update

The problems with the Openlayers plugin and the print composer last for years now, without a solution. As a consequence, try to avoid the Openlayers plugin when you need a print output. A new plugin, QuickMapServices, has been developed in the meantime. I suggest to try that.

Sorry, I can not reproduce the error. Can you try the current version of Openlayers plugin (1.0.0), and Qgis master? Print composer has improved a lot after Lisboa.

Also you can try reprojecting your data layer to EPSG 3857. I guess that's your project CRS.

Maybe related to this bug reports:




but seems to appear not in every case.

  • Thanks for the answer: Now I have the openlayer plugin and it worked!! How do I get qgis master on debian? Now I have this in te repository: deb qgis.org/debian wheezy main one more question: Can I improve the resolution of the background map? For printing it is very poor...
    – desputin
    Commented Nov 26, 2012 at 22:02
  • For the debian installation, you better open a new topic. I can't help you there. For the printing resolution, you can increase the dpi in print composer, but might get a map without background. Or select a larger paper format, and use pdf export or a pdf printer as output.
    – AndreJ
    Commented Nov 27, 2012 at 5:12
  • Hm with the printing resolution you misunderstood me. The map looks fine EXCEPT that the OSM-Resolution is bad. This doesn't seem to improve if I export with a higher resolution.
    – desputin
    Commented Nov 27, 2012 at 8:06
  • Hi @AndreJ! Since this is the accepted answer, would you mind adding a note that the Openlayers plugin does not support printing?
    – underdark
    Commented May 30, 2016 at 19:07
  • @underdark I guess the best advice is to avoid the plugin wherever possible.
    – AndreJ
    Commented May 31, 2016 at 5:44

For future readers who are viewing this post, this bug still exists at 2.12. Here's a visual example of the bug, screenshot from a pdf that I created using the Print Composer. All layers, as well as the Bing imagery basemap, were EPSG:3857 (WGS 84 / Pseudo Mercator). I've noted in red how the underlying imagery had shifted. This shift only occurs in the Print Composer output; everywhere else it aligned correctly. It sure looks like some sort of datum shift:

enter image description here

But it's not a datum shift. It's a Print Composer bug that shifts the map location of any (all? I'm not sure. At least Bing Aerial) OpenLayers basemap when exported to a pdf (png, too, I think). But this shift only occurs if there's a margin around the map in Print Composer - ie the map area is smaller than the paper size. Even by a millimeter (wierd, huh?)

Fortunately, Shankar's explanation (thanks!) provides a workaround. I'll expand his answer with these details:

To work around the bug, if you add a map to the Print Composer that contains an OpenLayers basemap, the map must fill the entire page size, without any margin (this is unfortunate, because white space around the map can help visually). To fill the page, go to the map's Item Properties panel (View > Panels > Item Properties, checked on). Expand the "Position and size" section. Note the X, Y, Width, and Height boxes; they define the map's origin point and extension on the page. Since we want the map size to equal the page size, we enter the page size values. For example, A4 paper dimensions are 210 mm x 297 mm (http://www.papersizes.org/a-paper-sizes.htm). So for a portrait-oriented map, enter: X = 0, Y = 0, Width = 210, Height = 297

  • these values assume that the "Reference Point" is checked to the northwest box.

Notice how the map fills the entire page. Now when you export to a pdf, the underlying basemap image will not be shifted.

  • 1
    Additional information! The plugin QuickMapServices does not appear to have this problem. I've done some informal testing with QMS, and the shift has not occurred. See romainbh's answer in the following: gis.stackexchange.com/questions/170347/…
    – Stu Smith
    Commented Nov 16, 2015 at 21:47

I think I have identified the problem. when printing if you set the position and size of the map layer in the composer exactly equal to the page size, the open layers match the vector layers, otherwise the openlayers get their extents from the page size and then fit the layer to the smaller map size, causing misalignment.

basically the open layers plugin is using the page size instead of the map size when choosing the area of the open layer to display when printing. As a work around just set the map size to exactly the page size in the composer.


5827 #13 has identified the cause of a problem with identical symptoms. The openlayers plugin is taking the page size rather than the map size as a reference.

  • 1
    Simon, welcome to GISse, and thanks for your input. In the interests of providing as much information in an answer as possible, it might help to provide a link to the bug report that you are referencing. Commented Aug 19, 2014 at 15:30
  • Unfortunately, the bug report referenced in the answer (hub.qgis.org/issues/5827) has been removed from qgis.org.
    – AndreJ
    Commented Jul 31, 2017 at 11:18

Lowering the dpi (while exporting) and the scale (e.g. from 1:500 to 1:3000) are some workarounds for this bug.


5827 #13 has identified the cause of a problem with identical symptoms. The openlayers plugin is taking the page size rather than the map size as a reference. so layout the google earth layer to full paper size.

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.