Repository navigation
Polar Projection PDF Issue #5895
Description
Python 3.4
Conda 3.18.3
Matplotlib 1.5.1
basemap 1.0.7
Adobe Reader XI
Trying to plot a polar projection with a custom shapefile results in an error when opening the PDF in Adobe Reader.
I am creating two orthographic projections (a southern and northern hemisphere).
basemaps.append(Basemap(projection='ortho', lon_0=270, lat_0=90., resolution='c', ax=axes[0]))
basemaps.append(Basemap(projection='ortho', lon_0=90, lat_0=-90., resolution='c', ax=axes[1]))
I then draw a full world shapefile on each projection:
basemap.readshapefile('Earth', 'globe')
...
plt.savefig('amaps.pdf')
Everything works fine here and both basemaps display with the proper lines and shapes drawn. However, when downloading the PDF and displaying it in Adobe Acrobat, you will get something like this:
amap.pdf (which looks fine if you view it in your browser, but try downloading it and opening it with Adobe Reader). We've determined that the problem arises when the coastline includes lon, lat pairs in the opposite hemisphere from the hemisphere that it is to be drawn in. So if you are drawing the southern hemisphere, you cannot read a shapefile that has lon, lat points in the norther hemisphere, and vise-versa.
Our workaround required creating two separate shapefiles, one for the northern hemisphere and one for the southern. So now it looks like this:
# drawing northern hemisphere
if polar and idx == 0:
basemap.readshapefile('Earth_north', 'nh')
elif polar and idx == 1:
# drawing southern hemisphere
basemap.readshapefile('Earth_south', 'sh')
# drawing all other projections
else:
basemap.readshapefile('Earth', 'globe')
This works fine but shouldn't be necessary.
Activity
mdboom commentedon Jan 21, 2016
It seems (at least on first read) that this is a basemap, not a matplotlib issue. Would you mind filing this under matplotlib/basemap, and feel free to reopen this issue if there's something on the matplotlib side that needs to be addressed.
WeatherGod commentedon Jan 21, 2016
but, why would it be a basemap issue in particular? Basemap doesn't have
any PDF specific code that I am aware of.
On Thu, Jan 21, 2016 at 3:13 PM, Michael Droettboom <
notifications@github.com> wrote:
mdboom commentedon Jan 22, 2016
Sorry -- I missed that it was PDF specific. I'll reopen.
mdboom commentedon Jan 22, 2016
Can you provide a complete example (with fake data) so I can reproduce?
avipersin commentedon Jan 22, 2016
Here is a link to the GitHub repo I made to illustrate the issue: https://github.com/avipersin/BasemapPDF.git
If you run basemap.py and open map.pdf in Adobe Reader you will see the problem.
tacaswell commentedon Jan 23, 2016
Can we claim that adobe is not implementing their own spec right? 😈
With acroread 9.5.5 it looks correct, but gives a cryptic warning in a modal window. Is that the problem?
The attached file opened fine with chromium, firefox, and okular.
WeatherGod commentedon Jan 24, 2016
For posterity, what was the cryptic error message?
On Fri, Jan 22, 2016 at 9:48 PM, Thomas A Caswell notifications@github.com
wrote:
tacaswell commentedon Jan 24, 2016
I have since removed acrobat, but from memory it was something like "This PDF is wrong, contact those who created it"
mdboom commentedon Jan 25, 2016
Thanks. With this I'm able to reproduce, on both Mac Adobe Reader DC 2015 and Linux 9.5 (which was discontinued and is fairly old at this point). Both pop up a dialog saying there is a problem with the file, but both seem to provide no additional information. This will be a fun puzzle 😱
mdboom commentedon Jan 25, 2016
I should add: On Acroread 9.5 on Linux is looks correct. On a Mac with DC 2015, it looks like this:
Fix matplotlib#5895: Properly clip MOVETO commands
mdboom commentedon Jan 25, 2016
The issue is that some shapes being drawn have shapes that are entirely made up of large numbers (1e30). My best guess is that these are continents entirely on the other side of the projection. These shapes aren't fully clipped by matplotlib's clipping algorithm -- instead a single "MOVETO" operation a location of (1e30, 1e30) is written out. I suspect this is what is tripping up Acrobat Reader. (The PDF spec doesn't really talk about range of numbers, but it's reasonable that they would reject numbers this large given that PDF is optimized for sheets of paper no larger than, say, a small planet).
Fixing the clipping algorithm to be careful about everything it emits seems to fix the issue. See #5911.
Merge pull request #5911 from mdboom/clipping-fix
Merge pull request #5911 from mdboom/clipping-fix
Merge pull request matplotlib#5911 from mdboom/clipping-fix