Latest Contributions by JoshuaBixby

I did a quick performance check of the code above using pre-computed centroids stored and indexed versus generating centroids on the fly.  The latter approach took over 5x longer to run, and that was on a fairly modest-sized dataset. ... View more

I am not sure what your unique identifier is for municipalities, so I went with "id." SELECT m.shape, m.municipality, s.parcel_count   FROM admin.MUNICIP m,        (SELECT sm.id, count(*) as parcel_count           FROM admin.PARCEL sp, admin.MUNICIP sm          WHERE sm.shape.STIntersects(sp.shape.STCentroid()) = 1       GROUP BY sm.id) s WHERE s.id = m.id If you only wanted parcel count by municipality, without the associated shape, then the subquery itself would do the job.  Since you want the associated shape, you need to join the subquery results back to the municipality layer for mapping purposes. Performance wise, I am not sure how the above code will do.  You mention 17 hours, that does seem excessively long.  There are several things that could be going on.  One could be poor or nonexistent spatial indexes.  Check the execution plan to make sure spatial indexes exist and are being used.  I am also thinking that converting to a centroid on the fly could cause a performance hit.  For the minimal storage hit of adding a point field, it might make sense to store both the parcel polygon and centroid and then index both of them.  Also, if the parcel count isn't changing very much on a minute or hourly basis, it might be worth considering computing it once a day and storing the value for mapping and reporting. ... View more

It seems you are using the older/original search cursor instead of the newer data access (da) search cursor.  Have you tried using the da.SearchCursor with a Python with statement?  Does that change the result? ... View more

I, too, would be interested if there was a way to see all of the layers and table views created with arcpy outside of ArcMap, but I haven't found a way yet.  Obviously within ArcObjects it is being done, but it doesn't seem to be exposed through arcpy.  I guess the logic is that if you are creating them in your code then you should have an idea what you have created and can delete them as well, i.e., track it yourself.  I wouldn't mind being wrong on this one. ... View more

A cursory performance check shows SQL postfix being the quickest against a file geodatabase and SQL prefix being the slowest.  Runtimes relative to SQL postfix:  SQL postfix (+0%),  List (+3%),  Set (+4%), SQL prefix (+14%).  Interestingly enough, having the data in a personal geodatabase nearly doubled the runtimes of every approach across the board. ... View more

Although I think the approach is sound, it is bad practice to use a built-in function name as a variable identifier, i.e., naming a list 'list'.  The code as written will work, but shadowing a built-in name could cause confusion further down in the script. Another option for finding unique values is to use the set data type, which inherently doesn't allow duplicates. #Create empty set  salesSet = set()  with arcpy.da.SearchCursor(table, ["Sales"]) as cursor:      for sale, in cursor:          #Add sales to set          salesSet.add(sale) del sale, cursor #Iterate through set  for sale in salesSet:      arcpy.MakeFeatureLayer_management(table, "tableView", "Sales = '" + sale + "'")      ...      ... A slightly different tack is to let the database engine identify unique values either through a SQL prefix with arcpy.da.SearchCursor(table, ["Sales"], sql_clause=('DISTINCT', None)) as cursor: or SQL postfix. with arcpy.da.SearchCursor(table, ["Sales"], sql_clause=(None, 'GROUP BY Sales')) as cursor: Performance wise, I am not sure where each approach falls out, but I can't imagine the differences being noticeable.  My personal preference is using DISTINCT in a SQL prefix, but I know that ArcGIS 10.1 had issues with SQL clauses in cursors, so using a set data type might work with more versions. ... View more

What is the backend storage format?  File geodatabase?  ArcSDE geodatabase?  I ask because there may be other approaches that work more efficiently if the data is all stored in a DBMS. ... View more

In similar situations in the past, I just resorted to using the pipe symbol or vertical bar as the field separator.  Although I have seen crazy data where people use commas, colons, semicolons, and slashes in places they shouldn't be; I seldom run across people using vertical bars in free-form text.  ... View more

The following shows the type of situation I caution about above: My original code would generate a distance of 266.7m for the given point on the lake above with a fetch angle of 337.5 degrees.  My guess is that you don't want the total length of the line, but the length of the first part ( Part(0) ) of the line, which is 96.16m. Assuming the lines will be built from the point outwards, which I believe will always be the case with this code, the following change to the last loop will return the length of the first part and not the length of all the parts.             for i in drange(0, 360, alpha):                 pl = linefromPolarCoord(i, distance, pt, SR).intersect(pn,2)                 pl = arcpy.Polyline(pl.getPart(0), SR)                 insertCur.insertRow([OID, i, pl.length]) ... View more

After how many records does it start to slow down?  It could be a memory management issue by looping over all buffers with one search cursor.  I realize 14.000 records isn't really large, but it may be large enough to cause an issue.  What about chunking the records up and only have search cursors of say 1.000 records, does that keep the speed up? ... View more

Coincidentally, this exact same topic came up in ArcPy Café the other week:  Split into equal length features.  A team member Dave (I don't know him other than his name is Dave) provided a fairly compact and elegant solution. ... View more

I think what is being asked is whether your DBAs have fully patched the 12c database, including the latest October 2014 patches from Oracle.  If so, that could be what is preventing you from connecting. Critical Information Regarding Oracle Update and ArcGIS - See more at: http://blogs.esri.com/esri/supportcenter/2014/10/23/critical-information-regarding-oracle-update-and-arcgis/ ... View more

My preference is always to script it out with arcpy, especially in cases like this where using the GUI could quickly become cumbersome. ArcGIS 10.3 introduces a new method for point geometries that fits the bill for this task:  arcpy.PointGeometry.pointFromAngleAndDistance.  Unfortunately, that likely isn't going to help you out here and now unless you are testing the prerelease version of it.  In the absence of that new method, you can roll your own using basic trigonometry.  Since we are rolling our own, I think it makes sense to create a function to go one step further and build the line: def linefromPolarCoord(angle, distance, point, spatialReference=None):     X = distance * math.cos(math.radians(90 - angle))     Y = distance * math.sin(math.radians(90 - angle))     return arcpy.Polyline(         arcpy.Array([point, arcpy.Point(point.X + X, point.Y + Y)]),         spatialReference     ) The above function assumes basic 2D/projected data, nothing fancy with 3D distances or lines.  The angle is degrees, distance is in units of the projection (meters for UTM), point is an arcpy.Point, and spatialReference is an arcpy.spatialReference for the projection being used. Since you want to work in decimal increments and Python's range is integer based, I suggest rolling your own decimal-based sequence function.  I like the accepted solution of drange on the following StackExchange question:  Python decimal range() step value. Assuming you have the 500 points in a point feature class (pointsFC) and a single water body polygon in a feature class (waterbodyFC), the following code might get you in the ballpark: alpha = 22.5 distance = pointsFC = waterbodyFC = fetchesTable = 'fetches' arcpy.CreateTable_management("in_memory", fetchesTable) arcpy.AddField_management(fetchesTable, "POINTID", "LONG") arcpy.AddField_management(fetchesTable, "FETCH_ANGLE","DOUBLE") arcpy.AddField_management(fetchesTable, "FETCH_DISTANCE","DOUBLE") with arcpy.da.SearchCursor(waterbodyFC, "SHAPE@") as searchCur:     for row in searchCur:         pn = row[0]         SR = pn.spatialReference     with arcpy.da.InsertCursor(     fetchesTable,["POINTID", "FETCH_ANGLE", "FETCH_DISTANCE"]     ) as insertCur:     with arcpy.da.SearchCursor(         pointsFC,["OID@","SHAPE@"]     ) as searchCur:         for row in searchCur:             OID = row[0]             pt = row[1].firstPoint             for i in drange(0, 360, alpha):                 pl = linefromPolarCoord(i, distance, pt, SR).intersect(pn,2)                 insertCur.insertRow([OID, i, pl.length]) The above code assumes the points are in the water body, and you are interested in the distance to the edge of the water body, i.e., the shore.  Using intersect might not be the best option if the water body wraps back on itself or has lots of bays because that could give a length that is more than the length to the shore.  That said, the code is meant to demonstrate a workflow that can be scripted. ... View more

I have engaged with the developer in the past to sort out some issues with it.  I can't recall how I first found it.  I just did a Google search on "mxdperfstat 10.2" (the 10.2 being important), and the second hit is to ArcGIS.com.  The same search with 10.1 didn't yield as good of results. When it comes to ArcGIS tools and scripts, I have always found it frustrating how scattered they are under different sites and even domains.  I have found using Google with its site: operator as being most useful.  I have read that Esri is near deploying a new site for scripts and tools, hopefully it will be better than our current situation. ... View more

There is something straightforward and likeable about "local disk is best," but the situation isn't quite as simple when we move into the realm of best practices and enterprise GIS.  Although I have experienced firsthand the performance and stability challenges of exposing file geodatabases over networking protocols, I am trying to recall whether I have seen it documented as being against best practice.  Is there a good, singular source for file geodatabase best practices or is it a best practice here and another one over there?  The GIS System Design Strategies Wiki has best practices scattered throughout it, but it wasn't until the 34th edition in the spring of 2014 that file geodatabases were included in certain sections of the Network Communications chapter. The struggle with implementing a local-disk-is-best policy in the enterprise is defining what exactly local means.  I don’t think anyone could argue that SAS and SATA aren’t local, but does local apply to Thunderbolt, eSATA, USB, Firewire?  If so, what about USB 2.0 versus 3.0?  What determines calling something network storage?  The presense of TCP/IP or maybe Ethernet?  Is iSCSI over gigabit Ethernet considered network and bad?  What about iSCSI over 10 gigabit?  Of course there are the different versions of SMB as well. I think there is value in working with best practices, but practices need to be defined in a meaningful way so they can be used by a wide range of users, including the enterprise. ... View more