Sign up ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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

share|improve this question
Desputin, Did you ever find a solution to printing high quality OSM print resolution? – C_K Apr 18 '13 at 17:10

6 Answers 6

up vote 2 down vote accepted

Sorry, I can not reproduce the error. Can you try 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 thats your project CRS.

Maybe related to this bug reports:

but seems to appear not in every case.

share|improve this answer
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 wheezy main one more question: Can I improve the resolution of the background map? For printing it is very poor... – desputin Nov 26 '12 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 Nov 27 '12 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 Nov 27 '12 at 8:06

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 ( 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. Good luck!

share|improve this answer
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:… – Stu Smith Nov 16 at 21:47

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.



share|improve this answer
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. – Tbb May 18 at 18:22
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 – juls May 19 at 9:42
At least better than screen prints. Thanks again! – Tbb May 19 at 9:44
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 May 22 at 13:46

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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. – Get Spatial Aug 19 '14 at 15:30

protected by Community Sep 6 at 18:33

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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