Latest Contributions by RichardFairhurst

You appear to be cumulatively adding the total shape length of the entire polygon to the perimeter variable for each point along the perimeter that you encounter.  The length between points would require a euclidean distance calculation between all point pairs that make up the part being added as you traverse the part. The Shape.Length field (row[3]) should already be the perimeter of the polygon if this shapefile was converted from a geodatabase feature class or calculated using the geometry calculator.  Did you mean to update the Shape.Length field after determining the perimeter?  If so you need to use an UpdateCursor, not a SearchCursor. I believe something more like this untested code should work if you wanted to get the euclidean distances from a shapefile that is using a Spatial Reference with linear units (however, Dan's option of using getLength from the geometry may be all you need to do): for row in cursor:   # Create the geometry object   #   feat = row[1]   partnum = 0   perimeter = 0   # Step through each part of the feature   #   for part in feat:     # Print the part number     #     print "Part %i:" % partnum     lastpnt = None     # Step through each vertex in the feature     #     for pnt in feat.getPart(partnum):       if pnt:         # Print x,y coordinates of current point         #         print pnt.X, pnt.Y         if lastpnt == None:           lastpnt = pnt         else:           perimeter += math.sqrt((pnt.X - lastpnt.X) ** 2 + (pnt.Y - lastpnt.Y) ** 2)       else:         # If pnt is None, this represents an interior ring         #         print "Interior Ring:"         lastpnt = None     partnum += 1 ... View more

Typically this occurs when the feature class/table is in Editor mode which won't permit the schema to be modified as long as edits are occurring, or the table is open in another session (including viewing it on the same computer in two different sessions of Desktop or in both Catalog and Desktop at the same time) and you cannot get an exclusive lock on the feature class/table.  Not as sure in the Online environment, but I expect the exclusive lock requirement still holds true.  The listed restrictions affecting Add, Delete and Calculate in the online environment include: Add, Delete, and Calculate are not available for copies of layers. Add, Delete, and Calculate are only available for hosted feature layers or tables. You must be the owner of the hosted feature layer, or an administrator of your organization. ... View more

If your Street Light table contains Longitude and Latitude in the WGS 1984 projection (used by Google and most GPS devices) or X and Y coordinates in the spatial reference you normally use locally, then the table is a feature class as soon as you use the Make XY Event Layer tool or right click the table and set up its XY Event layer option.  If it contains an ID that relates it to a pole position in a separate feature class, then you can calculate the X and Y coordinates of the poles into the pole feature class and join the pole feature class to the table and fill in the X and Y coordinates into the table.  After that the table can be a feature class using the XY Event layer option. In a sense, the latter situation is better, since if you repeatedly capture new GPS coordinates each time you inspect the pole or log a new bulb, outage or repair you will get minor variations in the coordinates that make it harder to tell what features should be summarized.  You always want the same pole coordinates each time for the one-to-many relationship so that it is easier to do Spatial Joins, summaries, or Collect Event operations to get counts of the number of bulbs, inspections, outages, repairs, etc and the one-to-many relationship allows you to achieve that.  You may have two sets of coordinates, one for the GPS capture of the bulbs, inspection, repair, etc, and a second for the pole position, but for accounting purposes and map displays I am sure you want everything to match up to the one pole coordinate pair every time. Normally for a printed map one-to-many relationships that would create overlapping features get mapped using summary values rolled up to the one pole point, rather than trying to show each individual event for the single position, and you include a group ID value label that relates the count to the individual line items shown in a separate table sorted by that group ID.  But the XY Event table allows you to overlap the points and do labeling, etc for the individual events when you need that.  But I find that maps which do display all of the overlapping events or filtered groupings of overlapping events are best to interact with live and use the Identify tool to see the individual event listings for a position without trying to show every distinct event as a separate visual item or label on the map. ... View more

As far as I know this is not possible for feature classes, which ArcCatalog displays.  Feature classes exist in ArcCatlog independent of all layers and have no query bulding capabilities.  Desktop never displays a feaure class directly like ArcCatalog does and always display feature classes as feature layers only.  Only feature layers have query builder functionality.  I think this would only be possible within ArcCatalog through a saved layer file created by Desktop. ... View more

I do not disagree with you that many items can be built into the base software.  However, if not for workarounds, 90% of my career in GIS would have been spent getting nothing done while waiting for Esri to support my work.  I normally have developed my own tools with VBA and .Net about 4 to 7 years in advance of when Esri finally implements any similar functionality.  So I workarounds are the nearly the only real salvation this software has ever had. I always acknowlegde workarounds in my ideas to show that I am aware of them and to tell Esri why the workaround is overly complex, painful, frustrating, or stupid so that they do not dismiss the idea as solved by the workaround.  I agree they are not off the hook, because few people go to the lengths I do to workaround their software limitations.  But when a workaround exists I want to make sure others are at least aware of them so that they can get something done while Esri ignores this site. ... View more

See this post and use my Monotonicity calculation to find routes that have M patterns other than always increasing. ... View more

I just make the code and value the same. It takes little time to create a table, add two columns, fill one in, dup with field calculator and create a domain from the table. ... View more

I just tested it to make sure nothing has changed.  A script run in Idle with the env.overwriteOutputs = True setting produces errors like this when attempting to overwrite an output with a tool. Traceback (most recent call last):   File "C:\Python26\ArcGIS10.0\temp_sums.py", line 26, in <module>     arcpy.Statistics_analysis(intable, outtable, stats)   File "C:\Program Files (x86)\ArcGIS\Desktop10.2\arcpy\arcpy\analysis.py", line 1089, in Statistics     raise e ExecuteError: Failed to execute. Parameters are not valid. ERROR 000725: Output Table: Dataset \\agency\agencydfs\CustomApps\rfairhur\Layers\Application.gdb\PARCELS_ASSESSOR_SUMS already exists. Failed to execute (Statistics). If the quote is true that env settings have no effect outside the script, then I have to consider this behavior a bug, since overwriteOutputs has never worked inside my scripts run from Idle.  However, this bug has existed since the old GP syntax and has never been addressed since python geoprocessing scripts were developed. Based on Curtis' post it does seem that the overwrite outputs works as a tool.  However, most of my scripts are for after hours batch processing, so it does not help me in that case.  The Exists() and Delete_management() approach will work in any set up, so I recommend using it to avoid a gotcha if you want to do stand alone scripts. ... View more

Yes, I am saying that based on years of having that environment parameter ignored.  I left it in my scripts, but always get errors that I am trying to overwrite existing files if that is the only parameter used to overwrite files in my script.  It was only the Exist() method and Delete_management() methods that have allowed me to use Scheduler or Idle for my scripts.  I don't think that option works at all outside of the Python window inside a live session of ArcMap or perhaps a tool run within an open ArcMap session.  Python has no innate interactions with ArcMap, and importing arcpy does not set your script up with full a Desktop like environment without interacting with an actual ArcMap session. ... View more

As a side note, all of my roads are in the same feature class and there is a coded domain attribute for surface type that lists dirt, gravel, paved, concrete, etc.  I do all of my edits to all road types in the one feature class.  So just by changing the surface type in that one feature class I simultaneously am removing the road from one surface category and putting it into another surface category.  Other fields indicate the maintenance status and the jurisdictional ownership of each road so that those kinds of changes can be tracked in the same layer and do not have to affect surface type.  (Attribute Assistant can automatically concatenate these three field codes together into another field so that there a single field to control symbology that can be combined with any other fields, since there is a limit of 3 fields for a multi-field symbology).  If I want to create separate feature classes that contain only one surface type (or maintenance type or ownership type) I can select each surface type attribute one at a time and export each selection set to a new feature class (I would never edit these layers, just overwrite them in a scheduled python script to update them from my source layer).  With this one layer and these few steps I can accomplishing everything you have to do above with the two separate layers. The only advantage I see from maintaining these features only in separate layers is that fields that apply only to some surface types and not to others can only be within the surface type feature classes where they are needed.  That reduces the need to replace Null values in those fields with Not Applicable or blank values for the surface types where those fields are irrelevant.  So I am curious, is that the reason these are kept only in separate feature classes or do you have some other business requirement that makes these separate feature classes your best option? ... View more

You should be able to do the following: 1.  Add both the gravel road feature class and the paved road feature class to a map in Desktop and make sure Desktop is in Data View, not Layout view. 2.  Select the gravel roads that need to be changed to paved roads.  Make sure no other features are selected in any other layers. 3. Right Click the gravel roads layer in the Table of Contents and choose the Selection option and then choose the Create Layer from Selected Features option to create a Selection Layer in the map with just your chosen gravel roads in it so that you can easily select the same roads later. 4.  From the Editor toolbar press the Editor button and the Start Editing option and choose the paved road feature class as the feature class to edit, or right click the paved road feature class layer in the Table of Contents and choose the Edit Features option and the Start Editing option. if both the paved and gravel feature classes are in the same directory and geodatabase then the edit session will apply to both of them (I am assuming that). 5.  Press the copy button in the Tools toolbar. 6.  Press the paste button in the Tools toolbar. 7.  Select the paved road feature class in the target dialog that appears if it is not alread selected and press the OK button. 8.  The roads should now be duplicated and selected in the paved feature class.  Any fields with the same name and type will still have the information that was originally entered in the gravel roads feature class, but any paved road fields that are not in the gravel roads feature class will be Null.  Make any attribute changes necessary to reflect the paved condition of these roads. 9.  Clear all feature selections. 10.   If the Editor session applies to the gravel roads as well as the paved roads then in the gravel road Selection layer you created in step 3 you can select all of its features and press the Delete button.  The features that changed from gravel to paved should now be removed from the gravel road feature class. 11.  If you are satisfied that everything worked as expected you can press the Editor button on the Editor toolbar and press Save Edits.  Then if you are done editing you can press the Editor button on the Editor toolbar and press Stop Editing. 12. You can remove the gravel roads selection layer you created in step 3 from the map Table of Contents. ... View more

Most of these behaviors can be done by Attribute Assistant in real time during editing in an edit session on a shapefile, feature class or table.  They can be set up in the Dynamic Value table to occur in response to feature creation, attribute updates, geometry updates, and/or manual triggering of a request to update all manual dynamic values (to prevent slow editing in cases where data that should only update after a series of features are created or edited, not as each feature is created or edited). Field calculations within a single record is possible with the EXPRESSION method, which is the most flexible Attribute Assistant method.  It can concatenate field values and strings and do other string manipulations like changing case (anything VB Script can do), process math equations, set date stamps, do conditional expressions, etc LATITUDE, LOGNITUDE, X_COORDINATE, and Y_COORDINATE all can auto update centroid locations of point line and polygons, and start and end locations of lines in response to feature geometry creation or changes. LENGTH can be updated for line features; however, area and perimiters of polygons is not supported, although that should be a simple enhancement. Summary statistics with intersecting features is possible with the INTERSECT_STATS method.  This could do a count of features if you autopopulated all points, lines or polygons with a field that always containeed the number 1 (Default value or Expression) and did a Sum with intersecting features. Summary Statistics across all records in a feature class or table is possible with the FEATURE_STATS method.  Unfortunately, it cannot do summaries based on a unique case field.  However, although I do not do this in real time, Python cursors and dictionaries can do this without generating a separate statistics table and outperform Summary Statistics, Join and a Field Calculation.  See my post on Turbo Charging Data Manipulation with Python Cursors and Dictionaries. ... View more

I am using list comprehensions all over my code now and have experienced no problems.  Until one crops up, I will continue to use them. ... View more