Latest Contributions by JoshuaBixby

I meant to include the following in my original reply but had to step away.  You can see what I am talking about by using three different ways to create an ArcPy Polygon and then return the WKT for all three: >>> polys = [ ...    arcpy.FromWKT("POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))"), ...    arcpy.FromWKT("MULTIPOLYGON(((0 0, 1 0, 1 1, 0 1, 0 0)))"), ...    arcpy.Polygon( ...        arcpy.Array([ ...              arcpy.Point(0, 0), ...              arcpy.Point(1, 0), ...              arcpy.Point(1, 1), ...              arcpy.Point(0, 1), ...              arcpy.Point(0, 0) ...        ]) ...    ) ... ] ... >>> for poly in polys: ...    print poly.WKT ...   MULTIPOLYGON (((0 0, 1 0, 1 1, 0 1, 0 0))) MULTIPOLYGON (((0 0, 1 0, 1 1, 0 1, 0 0))) MULTIPOLYGON (((1.0001220703125 0, 1.0001220703125 1.0001220703125, 0 1.0001220703125, 0 0, 1.0001220703125 0))) ... View more

What version of ArcGIS are you using?  I ask because there were some changes, I would argue bugs, with how serviceProperties behave differently in ArcGIS 10.3 than ArcGIS 10.2.2.  Not sure if that could affect isServiceLayer as well or not. ... View more

+1, automation is the way to go with tasks like this one. ... View more

Have you reviewed the Understanding how to use Microsoft Excel files in ArcGIS section of the Help, particularly the "few things to keep in mind" items? Is this an XLS or XLSX file?  What version of MS Office do you have installed? ... View more

Your problem sounds familiar, not sure if I have run into it before or helped someone who has. Anyhow, part of your problem is caused by misunderstanding the ArcPy Result object.  The result object from calling Polygon to Raster (Conversion), specifically the getOutput method of that result object, isn't a Layer object or even the name of a layer in the map document.  In this case, the result object is returning the path to the newly created raster dataset.  RemoveLayer is throwing an AssertionError because it needs a "reference to a Layer object representing the layer to be removed," which the string you are passing it from the result object isn't. It appears you are having difficulties enumerating layers in the map document.  Can you provide a code snippet where you run the geoprocessing tool and attempt to list all the layers afterwards? ... View more

I think past progress on this suggestion is a good indication of future progress, which is too bad because having an optional spatial filter parameter would be much cleaner than having to rely on SelectByLocation. ... View more

What if you try working with a subset of the records in the table, say 10%, does ArcCatalog still crash? ... View more

Great catch!  I reached a point where Background Processing was giving me enough headaches that I started moving more towards scripting ArcPy outside of ArcGIS Desktop.  ... View more

I understand, completely.  The fact that some of the sql_clause bugs took until 10.2.1 to get addressed is, well, frustrating.  Oddly enough, I just tried my code snippet on an ArcGIS 10.1 SP1 machine and it worked.  I thought ORDER BY was also impacted by NIM094797, but that doesn't seem to be the case. Overall, I have found the ArcPy documentation in the new 10.3 help to be either improved or expanded for quite a few objects, methods, functions, etc.... ... View more

Fair enough, now I understand the perspective you are coming from. If you haven't seen it already, you might be interested in the How is the data access cursor performance so enhanced compared to previous versions? thread over at StackExchange.  The first answer is from Jason Scheirer​, one of the arcpy.da developers.  In his response he explains how they optimized the performance of the new cursors.  There is also a link to some benchmark results. Although the sql_clause documentation has remained the same, the arcpy.da SearchCursor code samples have been expanded with ArcGIS 10.3 to include an SQL ORDER BY example.  The SearchCursor code sample is transferrable to the UpdateCursor. The sql_clause was buggy when the data access module was first released at ArcGIS 10.1.  I believe it was ArcGIS 10.2.1 where a couple bugs related to the sql_clause were patched. Below is a code snippet that creates a table with randomly generated values and then sorts against those values to update another field in order. import arcpy import numpy import random fc = #table location in file geodatabase random.seed(3.14) l = [] for i in range(1000000):     l.append((random.randint(0,100000000), 0.0)) narr = numpy.array(l, dtype=([('rand','i4'),('numb', 'f8')])) arcpy.da.NumPyArrayToTable(narr, fc) i = 1000 with arcpy.da.UpdateCursor(fc, ["rand", "numb"],sql_clause=(None,"ORDER BY rand")) as cur:     for row in cur:         i += 1         row[1] = i         cur.updateRow(row) ... View more

Richard Fairhurst wrote: Having said that, dictionaries can out perform the ORDER BY operation by a factor of at least 10 times the speed, since no disk access is involved, whereas Updating using the Order By operator has to retrieve and write to each record in order, which is very slow in my experience and severely impacted by the overall size of the table, whereas unsorted reading to a dictionary and sorting the dictionary is extremely fast. 10 times?  What backend storage are you using? As a quick test, I created a table with one million records and two fields.  One field held a randomly generated number and the other just an empty field to be updated in order of the other field.  When using an in_memory table, the ORDER BY approach was 300% faster.  When using a file geodatabases, the ORDER BY approach was 7% slower.  When using a personal geodatabases, the ORDER BY approach was the same.  Disregarding the in_memory example, file-based geodatabases don't take that much of a hit using ORDER BY with an update cursor (arcpy.da). The sorting of a dictionary might not involve any disk access, but the overall approach of the dictionary method surely does involve disk access.  Iterating over a search cursor to populate the dictionary hits the disk, and iterating over an update cursor to update records hits the disk again.  Although there is some overhead in having the database engine order the records, there is also overhead in iterating over the records twice instead of once. I don't have access to Oracle or SQL Server this morning, so maybe ORDER BY does perform significantly worse in this case.  At least for file-based geodatabases, I don't see a significant difference in performance. ... View more

What version of ArcGIS are you using?  I am running ArcGIS 10.3, and I don't have any issues with using ORDER BY in a SQL clause for update cursors.  That said, I do seem to recall problems with it back in ArcGIS 10.1 and possibly 10.2.0.  Anyhow, I am just interested in whether your error might be related to the version you are running. ... View more

I think we will have to agree to disagree on this one.  Unless an OP got little to no feedback and researched the answer himself/herself, taking functional code snippets from responses and repackaging them into a "final" answer seems like an easy way to abuse the point system.  Part of the learning process is reading the whole discussion and understanding what comment was the crux of the solution.  I really wish GeoNet's points and discussions were structured more like StackExchange/Overflow, but we have to make due with what we have before us. ... View more