Latest Contributions by JoshuaBixby

You are correct, at least with dragging and dropping between Desktop and Pro.  The lack of that functionality was brought up by beta testers.  I can't remember the specific response right off the top, but I wouldn't hold your breath waiting for it. Regarding the first question, ArcGIS Pro can work with AGS and SDE files.  In the Project pane, you can right-click the "Folders" and add a folder connection.  From the new folder connection, you can access AGS and SDE files and add them to your project. ... View more

Melissa, thanks for the update.  Interestingly enough, I looked up NIM096391 on Esri Support, and it has no information about it being fixed in any SP or version.  Hopefully the review you speak of will also look at updating the Status information of the bugs as well.  I just downloaded 10.3 pre-release and should be able to install it this weekend.  I look forward to testing the fix. ... View more

I have no clue on your last question.  On the other question, yes, it surely seems Esri is moving towards a per-user licensing model.  Beyond ArcGIS Online (AGOL), licensing is also supported through Portal for ArcGIS (Portal).  This latter option just got enabled with 10.3 pre-release so I am still figuring out the details of making it work. The issue you are seeing with extended start-up times has been experienced by beta testers and reported to Esri.  Right off the top, I can't remember if a specific issue was identified or if it was supposed to be fixed in pre-release.  Hopefully they do address it soon because "problematic" doesn't quite do justice to describing the impact on affected users. The hardest part about determining whether per-user licensing will work in the enterprise is that there are still lots of undefined aspects to the cost/license structure of per-user licensing and ELAs. ... View more

No, there aren't really better options, we are stuck with workarounds until it is addressed.  This concern was raised very early on by beta testers.  It is a known issue they want to resolve and are working on resolving, it just isn't resolved yet.  I can't say what the odds are of having it addressed by final release, but I am not holding my breath. Not to nitpick on semantics, but they are important in this case.  A user can run more than one instance of ArcGIS Pro, just not on the same machine at the same time.  The current per-user licensing model allows a user to run ArcGIS Pro on up to three machines, unless offline licensing is enabled, and then the limit is one. ... View more

I was really thinking it might be something specific to that machine, but obviously that isn't the case.  I would say or suggest opening Support case, but best case scenario would be a bug that will be very low in terms of priority since it involves personal geodatabases.  This is where I would just find a workaround and say c'est la vie. Good luck ... View more

Seems like a pretty deep or pervasive problem, which should provide some sense of urgency one would think, but it could also be the excuse for not addressing the issue at all.  I have seen the latter more than a handful of times. Thanks for pursuing with Esri Support and getting a bug logged. ... View more

10k records isn't that many, really.  I assume the limit or problem is tied to the number of records being returned by the UpdateCursor and not the number of records in the underlying dataset, right?  Also, have you tried the older arcpy.UpdateCursor instead of the arcpy.da.UpdateCursor?  I know the former is slower, but if it works and doesn't generate duplicate rows. ... View more

Do you have another machine to try it on?  Does this happen with all machines you are working on or just one? ... View more

What's making the MXDs grow so much?  Good question, I wish we had clear answers.  Part of it is likely user behavior, although it is unclear what all behaviors cause the problem, but another part is how the MXDs are structured (design structure) and how ArcGIS interacts with them.  Geoprocessing history may play a part in some of the MXDs, but it isn't the dominant issue with the majority of the MXDs. MXD bloat isn't an issue amongst GIS staff as much as the casual GIS user in our organization.  There are numerous worst practices that casual users seem to develop over time, and some of them may contribute to bloat, but there are limits to what can be expected from educating users on best practices.  The bottom line for us is that we have an issue, prevention has its limits, and so we need to explore ways of cleaning it up on the back end. Opening up MXDs and trimming geoprocessing history will shrink some files to varying extents.  What also works is just opening up MXDs and saving a copy using the ArcMap UI.  The shortcoming of this approach is that it is manual.  We are looking for means to automate cleaning it up for thousands or tens of thousands of files.  Right now, either spawning docDefragmeter from Python or shell scripting it works, it is just clunkier and slower than we would like. ... View more

Heard back from Esri Development, "this is very much a known limit."  It seems to a handful or two of folks in Redlands, this is "very much" known; unfortunately up until now, no one has bothered to share it with ArcGIS users by actually documenting it.  At least now they have a bug to document it and to document they aren't going to do anything to address it. I "very much" get this response too often, can't help but think there is a hashtag reply in it: #findanotherworkflow #SOOL. ... View more

When doing Python scripting in ArcGIS, I tend to favor native ArcPy methods over geoprocessing tools.  The geoprocessing tools are convenient, but that convenience can come with a performance hit, and the hit can be significant with some tools.  Even within the ArcPy realm, I have found methods in the data access module (da) noticeably more efficient than corresponding methods in the base site package (arcpy).  (I think this has been one of the main selling points of the da module from the beginning) # import functions from modules that are available but not commonly imported from collections import defaultdict from numpy import fromiter, dtype # sum area by ID stats = defaultdict(int) with arcpy.da.SearchCursor(inputshp, ['ID','AREA']) as cur:     for k, v in cur:         stats += v # sum SUM_AREA - using sum over an iterable of dict's values fieldsum = sum(stats.itervalues()) # create iterable and populate numpy array stats_iterable = ((k, v, 100.0 * v / fieldsum) for (k, v) in stats.iteritems()) tmp1 = fromiter(stats_iterable,                 dtype([('ID', 'i4'), ('SUM_AREA', 'f8'), ('PROZENT', 'f8')])) # Dump numpy array to table arcpy.da.NumPyArrayToTable(tmp1, out_table) del tmp1 del stats .... The code above only uses 2 arcpy functions, both of which are in the data access module.  On a randomly generated million-record test data set, cutting out most of the arcpy functions reduced the runtime by more than 75%.  Profiling the original code shows the bulk of the extra runtime comes from a single function: analysis.py:(Statistics).  I have seen this numerous times, i.e., scripts that call Statistics_analysis on large data sets get really bogged down.  I am not sure how large your data sets are, but if they are large and you want to speed them up, rolling your own functions can usually get you performance gains. ... View more

Thanks for sharing.  Given the ArcSDE SDK is more niche than VBA was back in the day, I assume it won't be given multiple stays of execution, which makes your thoughts on moving forward that much more relevant. Spatial partitioning through the FGDB API, now that could get interesting.  Good to know, and I will have to spend some more time thinking about it. I spend most of my time with Python and SQL, don't dive into the APIs much.  When the day does come, I look forward to seeing the next generation of se_toolkit-like tools. ... View more

Interesting post with some food for thought and good reminders.  Seeing these tests were run with se_toolkit, and the ArcSDE SDK won't be supported beyond ArcGIS 10.2, it makes me wonder how easy or hard it would be to run similar tests in ArcGIS 10.3 or beyond. Esri's DEPRECATION PLAN FOR ARCGIS 10.1 AND ARCGIS 10.2. states: ArcGIS 10.2 will be the last major release to support the ArcSDE SDK with the ArcSDE C and Java APIs. Today many other options are available for developers, including SQL, which is available as a result of the widespread adoption of spatial types, the File Geodatabase API (introduced in 2011), and ArcGIS Runtime SDKs that offer modern environments for the creation of compelling custom applications. I don't think the File Geodatabase API is really applicable here, which leaves "SQL" and ArcGIS Runtime SDKs.  Maybe it is a long week catching up with me, but I am struggling to see where ArcGIS Runtime SDK fits in here.  Thinking of these specific tests, even going down the SQL path seems onerous, or at least not clear at first glance. What options do you see for recreating these types of test post se_toolkit? ... View more