|
POST
|
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
08-30-2010
05:41 PM
|
0
|
0
|
859
|
|
POST
|
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
08-30-2010
03:21 PM
|
0
|
0
|
1006
|
|
POST
|
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
08-26-2010
03:17 PM
|
0
|
0
|
2623
|
|
POST
|
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
08-26-2010
07:22 AM
|
0
|
0
|
859
|
|
POST
|
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
08-25-2010
03:55 PM
|
0
|
0
|
1275
|
|
POST
|
Karl: I have attempted in incorporate the alternative code styles you have suggested. The messaging subroutines now take a parameter and employ the try: finally: syntax you suggested. The body of the code where the messages are sent have eliminated the external message variable and now embed the message text as a parameter of the message subroutines. I was not as clear on how to apply your ideas about the except blocks. I have not really ever read any documentation on Python that explains best practices with this syntax and was not clear on the options I have for limiting the except block behavior (most Python documentation I do find is excessively cryptic and offers almost no introductory level discussions that can be easily practiced by people new to the language). Please review my revisions and point out some specific cases where I can make improvements to the except blocks. I will also admit that the logfile is a new practice for me so perhaps my set up and usage of the logfile can still be improved. I think I know what you were getting at with your specific line comments (68 and 157), but I was not sure how best to modify the code to do the error checking. Probably if the user provided an unusable root directory for some reason, I should actually exit the application, but I have not implemented that in this version. Is that what you meant by reacting to a NameError? I reversed the licence levels as suggested. I have also deleted the insert cursor at the end of the routine as a clean up (something you didn't mention, but that I noticed in other similar code, so I implemented it). As someone new to Python I want to adopt best practices early and welcome your comments as a way to acheive that. I hope that you will take my response as a positive indication of my intention to apply good programming practices. At the same time, I did not feel that the comments you have made resulted in any real changes to the core code that actually carries out the objective of what the tool is designed to do. The tools works very well for my needs, and I hope could be a starting point for others with similar needs to mine. I do not know whether this tool has much application to things you may do, but I would hope that you would be kind enough to point out where it works, so that those who may benefit from it will take a look at it with the improvements that I have made. Rich
... View more
08-23-2010
03:53 PM
|
0
|
0
|
674
|