Latest Contributions by RichardFairhurst

You did not say which version and licence level of ArcGIS you are using or if this is a one time process or something that needs to be run multiple times.  However, I normally approach this type or problem in 3 steps. The first step is to get the data in order.  If it is already ordered on your basiin field the objectID should provide your base sequencing values.  If it is not in order and you are using ArcGIS 10 with an ArcInfo licence there is a built-in permanent sort records tool that will sort on your basin field.  If you have ArcGIS 9.3 you can use the script and tool at this post: http://forums.arcgis.com/threads/12385-(Again-Sorry)-Serial-number-for-the-records-in-the-attribute-table?p=37288#post37288 You also could use ET Geowizard from http://www.ian-ko.com/. It has a permanent sort tool that is included in the subset of tools that are available for free with unlimited use. Based on your descriptionm, you may first want to develop a query where you get just the values that have no numeric portion to do your sort on.  The query might work if it was something like:  NOT("BASIN" Like '_0%' or "BASIN Like '__0%') Once the data is ordered, I perform a Summary on the basin field and get the Min ObjectID value.  Getting the Min ObjectID value may involve creating a field and calculating the OID values into it, since for some reason the Summary field does not like using the ObjectID field itself as a summary input.  (It may be possible just to type in the ObjectID field name and avoid that extra step, but I have not tried it).  ONce you have the summary, you could also add another field to the summary table create your unique offset values for each basin value at this point.  If this is a one time set up just do it manually. Now you perform a join and calculate the sequenctial field.  Using pseudo VBA (for 9.3) the value you want will be: [OrigTable.Basin] & format([OrigTable.ObjectID] - [SumTable.MinObjectID] + [SumTable.Offset], "0000") If you have ArcGIS 10, do not use Python on the join calculation as it will run 20 to 50 times slower than VB Script.  The VB Script expression would be: basinNum = [OrigTable.ObjectID] - [SumTable.MinObjectID] + [SumTable.Offset] If len(basinNum) < 4 Then   [OrigTable.Basin] & left("0000", 4 - len(basinNum)) & basinNum Else   [OrigTable.Basin] & basinNum End If Potentially this could also be done in ModelBuilder, but the unique starting number would have to be hard coded into a calculation.  I hope this helps. ... View more

I had that originally...tried changing it back just now, so script is currently import arcpy mxd = ("G:\search_zoom\search_zoom.mxd") df=arcpy.mapping.ListDataFrames(MXD, "Layers")[0] Layer = (mxd, "section", df)[0] df.zoomToSelectedFeatures(layer) df.scale = df.scale * 1.1 arcpy.RefreshActiveView() with error of: File "G:\kpw\arc_server\auto_assessment\search_zoom\zoom2selected2.py", line 3, in <module>     df=arcpy.mapping.ListDataFrames(MXD, "Layers")[0] NameError: name 'MXD' is not defined I originally had the arcpy.mapping.... starting line 2 as well, but that gave me the same error, so I removed it and just went straight to a direct reference and then it read fine until the next arcpy.mapping.... What am I missing? Python is case sensitive and the error is indicating that you have changed the case of the mxd variable in the 3rd line, which rather than using the assignment of the variable in the second line is being interpreted as a new unassigned variable.  You have the same problem with the variable called Layer/layer.  Be consistent with your variable spelling cases.  Change the code to: import arcpy mxd = ("G:\search_zoom\search_zoom.mxd") df=arcpy.mapping.ListDataFrames(mxd, "Layers")[0] Layer = (mxd, "section", df)[0] df.zoomToSelectedFeatures(Layer) df.scale = df.scale * 1.1 arcpy.RefreshActiveView() ... View more

I do not yet have ArcGIS 10, but the help for the tool lists a set of specific requirements of the input polygon layer that put some pretty severe limits on what will work with the tool.  http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//007000000009000000.htm  Are you sure that you have a polygon layer that matches all of the requirements?  (I can see I will need to continue to update and use the custom coded MapBook application code I have developed, since there is no way I can make my map series conform to these limitations in any way.) ... View more

(Edited) I have deleted my original suggestion after rereading your code.  I realized I had misread the code and that my suggestion about the class name capitalization could not be the source of the problem (and your revised code proves that).  I just don't like the idea of using arcgis as a class name or variable, since it could be a word that ESRI may reserve at some time (or may have already reserved based on the fact that you seem to think that your code is generating a conflict with an existing resource).  Try changing the arcgis variable name to something else and see if the same error is generated.  If it is, something other than a conflicting resource is at work. I also just noticed your comment where your wrote "# Give the object any other name than 'arcgis' and it works..".  This indicates that arcgis is a reserved name in some form.  I have not looked for documentation on that being a reserved word, but based on your code's behavior it does seem like that is somehow at the root of the code failure.  (I also agree that the namespaces should prevent the conflict normally, but if somehow namespace ambiguity arises then I guess odd behaviors are possible if the namespaces are not clarified.  At least that is the case in .NET.  Most likely the import of arcgisscripting introduces an arcgis object from that namespace and your code creates ambiguity with that object name.) ... View more

Just a note to improve performance on a portion of the code Jeff provided.  Make it a practice to get the index of any field outside of the loops you create and directly use the field index in the loop.  The FindField operation does a schema search loop that really only needs to be done once outside of your loop.  Repeating loops within loops drags down performance.  Using the index value directly inside the loop acts like direct array access to the field and does not cause a secondary hidden loop to occur for every record your loop processes.  (From best practices with cursors training at the ESRI conference).  So the sample code should be revised as follows:     Dim pTableCursor As ICursor     Dim pRow As IRow         Set pTableCursor = pTable.Search(Nothing, True)     Set pRow = pTableCursor.NextRow         Dim fIndex as Long     fIndex = pTable.Fields.FindField("FeatureClass.FieldName") 'fully qualified field name from joined table     Do Until pRow Is Nothing         Debug.Print pRow.Value(fIndex) ' removes a hidden loop required to find the field         Set pRow = pTableCursor.NextRow     Loop Hope this helps. ... View more

I beleive you want the "Explode" tool if you want to convert your line from a sngle multi-part line segment to two separate single-part line segments.  All attributes are duplicated by the explode tool for each new line segment.  It also works for mulit-part polygons, which some tools create by default.  The Explode Tool is available on the Advanced Editiing Toolbar. ... View more

My script converts these event-tables to event-layers (MakeRouteEventLayers), before the part that I have shown does it's job on the EventLayer. Could this cause the slow-down? I also use linear reference event layers and do find that they slow down calculations regardless of what database is used to store them.  I find that LR event layers want to refresh with calculations and that this is a relatively slow process.  They seem to treat every field as though it is affecting the positional data of the LR event and seem to perform some internal check to reverify the event goemetry.  I also find LR event layers do not like joins used in conjunction with calculations and throw errors.  So LR event layers are a bit testy. Normally I try to calculate values that are not dependent on the LR event geometry directly into the underlying table (use the tableview creation tool in modelbuilder to access the table for calculations in your script).  The main problem with this approach can be that any precreated LR event layers may not immediately reflect the calculated values because the calculation does not always trigger a refresh of the LR event layer in memory (which can be good for performance but not so good for immeidate feedback on symboology or labeling of your map).  If I want to calculate a field that will be immediately reflected on the map, I usually have to calculate it directly on the LR event layer and take the performance hit, or else destroy the LR event layer and recreate it after I have calculated the value in the underlying table.  The second approach is often faster.  At the very least, test a calculation done directly to your underlyinng table and then creating your LR event layer for a contrast on the speed of the two approaches. ... View more

Hi. Thanks for your modified code.  I am now using this.  I have now added more complexity to the IF statement by utilising 'NOT' condition.  That is, instead of evaluation if something is present, it is evaluating if something is absent.  This is shown is a subsection of my script below.  I am finding the IF statement to be quite useful. scursor=gp.SearchCursor(Clip) row=scursor.Next() if row.GetValue("Region") <> 'Murray Inland':     gp.MakeFeatureLayer("Boatmap_Index.shp", "Boatmap_Index_lyr") del scursor I am glad you found my code useful and I hope it helps you understand how While loops are structured.  As far as your new code, you are again testing just one record out of what I assume could be many records.  That seems arbitrary to me.  What if the first record has a value of "Murray Inland", but the second record does not?  Wouldn't you want to create the layer then?  Or rather, wouldn't you want to create a layer file and filter out values with "Murray Inland" through a definition query? Since I don't know how you are using this information in your model, I cannot predict exactly what behavior you are looking for.  However, normally when looking at multi-record data in combination with conditional requirements, its is rarely a simple matter of looking at one arbitrary record and making a decision based on the information contained in that one record alone.  So think this through a little bit more to make sure it really is doing what you want. ... View more

Your code is indented incorrectly and the way you have written your code does not process the while loop.  The way you have written it, only one row will be read and tested and then the break statement will cause the while loop to be exited (in other words, you are not processing a while loop at all, just one record of the table).  I can see why your code now avoids an error or an infinite loop, but that is because it is only considering one record and then stopping.  If the code you wrote is actually doing what you want, get rid of the while loop, because it is not being used. To make your code run as a true While loop and process multiple tests where you could actually delete any or all of the files where you encounter matching true conditions in any of your records, you must indent the code as follows.  Also, now you must use the Exists test to avoid the possibility of attempting to delete a file multiple times and you can no longer break out of the loop.  (The break only works with a single test.  Now that you have multiple tests, a break with any of the conditions would cause only the first of the conditions encountered to cause a file deletion, but leave all of the other files untouched even if another record in the feature class would meet the conditon for deleting a different file).  import sys, string, os, arcgisscripting gp = arcgisscripting.create(9.3) Mooring_Structure = "Mooring_Structure.shp" P_L = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines" Clip_Feature = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Clip_Feature\\Clip_Feature.shp" gp.FeatureClassToFeatureClass_conversion("\\\\Atlas\\data\\geodata\\statelamblands\\moor_struct\\arc", P_L, Mooring_Structure, "") gp.workspace = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Clip_Feature" scursor=gp.SearchCursor(Clip_Feature) row=scursor.Next() while row:     if row.GetValue("Region") == 'North Coast':         if gp.Exists("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp"):             gp.Delete_management("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp")     if row.GetValue("Region") == 'Murray Inland':         if gp.Exists("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Contour.shp"):             gp.Delete_management("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Contour.shp")         if gp.Exists("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp"):             gp.Delete_management("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp")     if row.GetValue("Region") == 'South Coast':         if gp.Exists("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp"):             gp.Delete_management("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp")     row=scursor.Next() # This line must be indented one level to be inside the while loop.  If it is not, the while loop never advances the row and becomes infinte. del scursor ... View more

I agree with Chris that FGDBs have excellent performance and that what you are describing is unusual (for me calculations on 120,000 records on an unjoined table normallly complete in under 2 minutes on my FGDBs).  Is your FGDB on a local drive or network drive?  If it is on a network many other things could be causing the performance degradation other than the FGDB itself.  You need to provide a bit more description on how you set up your FGDB, verify that there are no system limitations that are affecting its performance, and test a few other alternative setups prior to concluding that FGDBs are at fault and fundamentaly flawed for use with the Field Calculator. ... View more

You need to enclose your code in code tags (press the button that looks like "#" on the message buttons and place you code inside the tags).  Your error could occur due to not placing the code in the correct indentation level (but I cannot tell since your indentation is lost without the code tags).  I have added some exist checks that may solve the error problems.  I also believe it should be indented as follows and you should include the break statement after the deletion occurs since there is no point in processeing any more records after the shape file is deleted.: import sys, string, os, arcgisscripting gp = arcgisscripting.create(9.3) Mooring_Structure = "Mooring_Structure.shp" P_L = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines" Clip_Feature = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Clip_Feature\\Clip_Feature.shp" if gp.Exists(Clip_Feature):   gp.FeatureClassToFeatureClass_conversion("\\\\Atlas\\data\\geodata\\statelamblands\\moor_struct\\arc ", P_L, Mooring_Structure, "")   gp.workspace = "C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Clip_Feature"   scursor=gp.SearchCursor(Clip_Feature)   row=scursor.Next()   while row:     if row.GetValue("Region") == 'North Coast':       if gp.Exists("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp"):         gp.Delete_management("C:\\Daves_Stuff\\ArcPad_Data\\Standard_Layers\\Lamberts_Projection\\Pts_Lines\\Mooring_Structure.shp")       break     row=scursor.Next()   del scursor ... View more

Patricia: Your problem is with the line of code below:     pQueryFilter.WhereClause = "OccurredDate1 >= DateFrom And OccurredDate1 <= DateTo" This would be translated as though DateFrom and DateTo are actual fields in your feature class (like OccurredDate1) rather than as date values that the user is supplying.  In case Lance's suggested syntax does not work try the clause below to replicate the format you said worked: pQueryFilter.WhereClause = "OccurredDate1 >= date '" & format(DateFrom, "YYYY/MM/DD") & "' And OccurredDate1 <= date '" &  format(DateTo, "YYYY/MM/DD") & "'" ... View more

The labelling engine will always run last and cover all other objects if you continue to auto generate the labels (ArcGIS descktop also has different layers it builds to create a drwaing and I believe the label layer is the last to draw and always on top).  There is no mechanism for covering the labels in that case. I believe you would have to covert the labels to annotation or graphics to make them a layer that can be covered.  At that point they become static and will not regenerate in response to panning or zooming of your data frame.  I have never tried to get the effect you are looking for, so you would have to experiment on both the initial placement properties of your labels and then the conversion to be able to rearrange the layer order. Rich ... View more

I can see why it falls into infinitiy.  With a While loop on a cursor you must always make sure that before you add any other code that the last line within the while loop is the code that advances the cursor, i.e., "row=scursor.Next()".  If this line of code is not at the end of the while loop block the cursor never advances at all within the loop and the while statement never becomes false (i.e., say the first row does not meet your conditiion, but that row is the only row that ever gets evaluated and never stops being evaluated so the loop never ends)  The code below is exactly the same as all of the suggestions above but note that the "row=scursor.Next() statement has been repeated inside the while loop and therefore the cursor position now advances with each pass of the while loop. scursor=gp.SearchCursor(Clip_Feature) row=scursor.Next() while row:     if row.GetValue("Region") == 'Murray Inland':         for ext in [".shp",".shx",".sbn",".dbf",".prj",".sbx"]:             os.remove("C:\\Temp\\Contour"+ext)     row=scursor.Next() del scursor I cannot see any obvious connection between the trigger row value and the action being done.  But I guess if this is what you want, fine.  Also, it seem the trigger only needs to occur once, but there is no certainty that there will not be multiple rows that meet the condition.  If that is the situation, the loop should be exited after the first instance of completion of the for loop (i.e., put the exit line within the if block at the same level as the for statement prior to the row advance statement).  Not sure what Python syntax is for dropping out of a while loop (I'm an ArcObjects guy still and not up to speed on all things Python), but I am sure such a statement exists. Rich ... View more

Python absolutely sucks with joined data.  Python is up to 5000% slower with a join in place than VB script, so you should absolutely avoid doing calculations using Python with a join in place whenever possible.  Joins and the field calculator should only be used in scripts where a data transfer is occurring from the child table to the parent table (and if it is a simple transfer use VB Script syntax).  I don't see that your calculation in this case is dependent on the join (but I may be missing something).  Joins with Python also can cause out ot memory errors that cause unexpected failures as you can see. If this is scripted and the calculation you want to do is possible outside of the join reorganize your operations to do the calculation outside the join and then create the join.  Everything will perform much much faster and failure will be minimized.  If the join is necessary for transferring data, do just that operation and then break the join to do any other operations that transform the data.  You will save an immense amount of time.  (Python is necessary for advanced expressions, but never perform them with a join in place).  Breaking the transfer and the transformation into separate operations will actually save you time if you manage teh joins so that they are removed prior to and advanced calculations. ESRI has confirmed the slow performance of Python on joined tables and has no fix at either ArcGIS 9.3.1 or ArcGIS 10.  VB Script syntax always performs faster for simple transfers between joined tables, so for any simple transfers use VB syntax (simple means only without any VB specific functions or methods, just [field] tranfer syntax).  The VB syntax on joined tables always takes advantage of indexed join fields, but the Python syntax does not seem to, which is why the calculations are always faster with VB script.  (Of course this means you should create indexes on your joined fields before doing the calculations and use VB script syntax) I also have never been able to use an updatecursor on a joined table, so I don't know of a way to make that work (seems like ESRI somehow does it, but they have never indicated how as far as I have seen). Hope this helps. ... View more