Bing Maps gets its data from HERE maps – so if you have a problem with inaccurate maps, then you can't really blame Microsoft for that. Now when you export to a pdf, the underlying basemap image will not be shifted.The problem could be twofold. Notice how the map fills the entire page. these values assume that the "Reference Point" is checked to the northwest box.For example, A4 paper dimensions are 210 mm x 297 mm ( ). Since we want the map size to equal the page size, we enter the page size values. Note the X, Y, Width, and Height boxes they define the map's origin point and extension on the page. To fill the page, go to the map's Item Properties panel (View > Panels > Item Properties, checked on). 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). I'll expand his answer with these details: Even by a millimeter (wierd, huh?)įortunately, Shankar's explanation (thanks!) provides a workaround. 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. At least Bing Aerial) OpenLayers basemap when exported to a pdf (png, too, I think). It's a Print Composer bug that shifts the map location of any (all? I'm not sure. It sure looks like some sort of datum shift:īut it's not a datum shift. This shift only occurs in the Print Composer output everywhere else it aligned correctly. I've noted in red how the underlying imagery had shifted. All layers, as well as the Bing imagery basemap, were EPSG:3857 (WGS 84 / Pseudo Mercator). Here's a visual example of the bug, screenshot from a pdf that I created using the Print Composer. For future readers who are viewing this post, this bug still exists at 2.12.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |