After having spent the better part of three hours importing maps (from arcmap) in arcpro it (arcpro) crashed and I lost all my imports.
My patience with ESRI's software engineering wore out years ago. Bugs that are never fixed. Software versions that are incompatible and require us to keep ponying up thousands of dollars. And now this.
ESRI: do you think that you could perhaps make a product that has adequate QR before it is unleashed on your suffering customer base?
Please don't bother calling me back. I am not going to go through that catechism about what platform, what version, blah blah blah.. The crash report has been submitted. There is no way I am going to spend hours trying to reproduce it. Don't call: just make reliable software. Is that asking too much?
Oh, and here is a followup. I started over and reimported maps, saving my work each import. I now have 15 maps imported into my project. Now, when pro starts and I open that project I see a spinning blue wheel for several minutes before anything displays.
Not that only. For various reasons I renamed some of the maps after they are imported. That takes between one and two minutes! How can something as simple as changing a name of a map, no georprocessing, no redrawing, no exchange of data over a network, how can that take about 2 minutes?
This product is basically unusable.
Hi Robert. I feel your frustration and as a representative of technical support, trust me, we do want to help. But you put me in a tough place replying to this by saying not to call you, and that you don't want to work with us to reproduce the issue. Did you include your email address and a description on the crash report that you submitted?
There are a number of factors that can lead to performance issues and we would need to look at those specific to your situation, where the data is stored, where the project itself is stored, etc. In short, I can say that importing maps into a Pro project does not, in general, across all users, cause Pro to crash. We obviously wouldn't release that. So we need to investigate your specific case. But we can't if you don't want to work with us.
If you want help, please contact technical support. We're here. On your terms.
Thank you.
Kory
There has to be something seriously wrong. I am working on a Macbook Pro, using Parallels with Windows10 and 8G of memory dedicated to the windows VM.
Let's put aside the crash. It will be quite time consuming to replicate. Can we instead concentrate on the speed of Pro.
I have imported 15 maps, one at a time, and I stopped there because it was shortly therafter that my original import crashed (I had not been saving the project each import, which is why I lost everything). When I now fire up Pro:
1. It takes 4 minutes to become responsive (ie just to present the catalog, no actual map drawing)
2. To draw one of the imported maps, chosen at random, 6 minutes to draw.
Now, I accept that ESRI could not possibly have expected their users to accept those delays. But I am not doing anything other than documentation says I can do. My maps are reasonably complex, and they use as basemaps .bds files from Business Analyst (v 1.4). Could that be the issue? Is Pro, in its default configuration, trying to access the internet with some attendant delay?
When you say that you're not doing anything other than the documentation says you should do, are you referring the help on running Pro with Parallels on Mac: Recommendations for running ArcGIS Pro on a Mac—ArcGIS Pro | ArcGIS Desktop
Yes, and also the path to convert maps from arcmap for use in arcpro
In the string here we never got the version of Pro that you're using.
You say that you have reasonably complex maps that are using
as basemaps .bds files from Business Analyst (v 1.4)
Did you mean v 10.4?
What .bds files are you using in those maps that you're importing? And/or are the mxds starting from the standard Business Analyst mxd?
I know this isn't where you wanted to go with this post, a whole bunch of questions to try to help figure out what is going on, but any additional information you could provide would be helpful. We can see how we do trying to troubleshoot this through GeoNet, but honestly we might make more headway more quickly through a support case.
Yes, I meant 10.4. And I was wrong in saying that the maps
use bds layers. Read on.
My maps most use maps that are
supplied with BA 10.4 . The geographic features
use featureclasss in a file geodatabase NAVTEQ_2014_Q3_NA.gdb
The demographic layers in BA use .bds datasets,
but I replaced those with stripped down
feature classes covering just the geographic
area in which I am interested. I may still have
those bds layers in some maps, but they are
not turned on.
I have asked a colleague to install the Pro project
I created on a laptop running Windows10 natively
to see whether the speed problem persists.
No answer on that yet.
BTW: I don't think I am using the terminology
properly. What constitutes a base map?
I ask because when I use the arcpy package
and examine the layer.isBasemapLayer attribute
it is never TRUE for any of the layers in any of
my maps.
In Pro: Author a custom basemap—ArcGIS Pro | ArcGIS Desktop
ArcMap: Working with basemap layers—Help | ArcGIS Desktop
Let us know about what happens on the native Windows machine.
Kory
I can file a bug report on the speed.
I am running Pro 2.1.1
I really cannot undertake to reproduce the problem.
That will take hours of my time without any guaantee
that I can reproduce the exact sequence of steps.
My employer does not pay me for that.
However, the speed issue is more tractable, and
reproducible. I had the same result today when
I fired up Pro. So I wold prefer we concentrate on
that. I suspect the two problems are related.
Rob Stevens