ArcGIS Pro 2.5 - Export Layout takes 20 Minutes

16049
22
Jump to solution
02-27-2020 09:13 AM
by Anonymous User
Not applicable

Hello. Almost every time I export a layout in ArcGIS Pro 2.5, it takes 20 minutes. I tried turning on and off different layers, locking elements, exporting to my local drive, changing DPI, changing the file type, etc. I am not loading a lot of data. The "preparing to export" portion takes about 18 minutes and then the "export in progress" takes about 2 minutes. Is there a certain setting that I am missing? This did not happen with earlier versions of Pro. #arcgispro2.5 #export #slow #performance

22 Replies
ZachStanford
New Contributor III

This happens to me too, happening right now in fact. It does seem to happen more frequently with cloud-based layers. It's also not entirely predictable. Sometimes, works just fine. Other times, reports are 30 minutes late because ArcGIS Pro spends it "Preparing to Export". I like this Python idea. Just tried that while Export was in process, but stuck on Initializing Python Interpreter... 

UPDATE: I switched Wi-Fi networks, to a more "open" network, and it all went through within 15 seconds (after 30+ minutes waiting on the "Secure" network). Can't prove a connection to the internet, but seems related.

0 Kudos
JeremyDavies
New Contributor III

Having experienced incredibly slow exports of layouts with all versions of Pro (now on 2.8.3), even with all data being local, I decided to see how a python export script performed. In this particular case, it was just taking a few  minutes to export via the GUI and not twenty (although I've had it take even longer with complex layouts!), but still painfully slow. I did a bunch of tests, and here are the average export times for this particular layout:

Export time via the Pro GUI: 2 minutes 55 seconds

Export time via the Python window: 22 seconds

So Python was 8x faster! And when I experimented with some exports of maps with raster data (heat maps), the difference was even more pronounced-- almost 3 minutes vs 12 seconds.

I guess I'll be digging in to python export options for a bit, at least until the Pro GUI can handle exporting my layouts in a more timely fashion.

Here is the code I used:

aprx = arcpy.mp.ArcGISProject("CURRENT")
for lyt in aprx.listLayouts("TestLayout"):
lyt.exportToJPEG("C:\...\Maps\PythonExport_HeatMap", 200)

0 Kudos
KeithAddison1
Occasional Contributor III

I can report that this happens to me seemingly at random.  One day its quick the next day glacial, same settings and everything.

RoisinMc
New Contributor

Using ArcGIS Pro 2.9 with latest patch and I have the same issue: fast from the python window (30seconds-1minute), and very slow (about 8-10 mins) from export layout...

0 Kudos
DavidRoberts8
New Contributor

Yes, exactly the same issue. Fast with python, very slow with export. Pretty basic functionality like this should work! Same issue on different maps, different wifi connections, different export sizes etc.

0 Kudos
StephenKing3
New Contributor III

Hello, did anyone find a solution to this? I have installed 3.1 and started getting the same issue. It takes a long time to export the layout and in some cases, the legend doesn't export correctly. If I use Python it seems to work fine. Thanks.

jve01
by
New Contributor

Hello,

I was able to diagnose the issue for my particular problem. I was reusing a project file which over time accumulated numerous layouts which in turn increased the time to export the layout to a PDF. The solution was to export the layout as a pagx file and then open that layout file in a fresh aprx project. Problem solved. If you continue to run into the issue here is some python code that works as well:

import arcpy.mp as mp

# Get the current project
aprx = mp.ArcGISProject("CURRENT")

# Get a list of layouts in the project
layouts = aprx.listLayouts()

# Select the first layout in the list (you can modify this as needed)
layout = layouts[0]

# Set the output path and file name for the PDF file
output_path = r"C:\path\to\output\folder"
output_file = "output.pdf"

# Construct the full output file path
output_pdf = output_path + "\\" + output_file

# Export the selected layout to PDF format
layout.exportToPDF(output_pdf)

 

I hope this helps!

-J

AaronBaumgarden
New Contributor III

Hello,

We just upgraded from 3.0 to 3.1.2 last week and started having this same issue; exporting layouts taking way longer than they should. After a few days of testing various strategies, we decided to create a brand-new Pro project and voila, any layout file will export in mere seconds like it used to. 

While Python seems to be a solution for many, this appears to be a version compatibility issue since the .aprx files were created in a prior version of Pro. This seems to align with all the reported problems in this post because nearly everyone says they just updated from version 2.x or 3.x, or patched, and started having issues exporting a layout.

Doesn't look to me like the file is being successfully upgraded to the latest version when it is saved for the first time. That, or some other bug is affecting the export process. Thoughts, Esri?

Thanks,

Aaron

0 Kudos
MatthewGeorge
Occasional Contributor II

Looks like there's plenty of feedback here but just wanted to add to the list of users with this issue. We're running Pro v3.1.2 and experience extremely slow Export Layout times.

Workaround was to implement a Script Tool that replicates the functionality of the standard Export Layout GUI.

We initially thought it was because we were using Feature Services instead of direct connections to the databases or local data but looking at the info here it's not necessarily the case. We did find that it seems to be worse for established projects (had plenty of use) when compared to "fresh" projects OR read only versions of the established projects.

Has been raised with Esri Australia support.

0 Kudos
dragana118
New Contributor

Same issue here, we have been using a couple of .aprx projects for a while, and the map export is taking longer and longer.. we cannot start a new project from scratch, because the existing ones involve a large number of data sources, plus it does not make sense if the same problem will appear again after a while.. 

0 Kudos