|
POST
|
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
09-02-2010
01:13 PM
|
0
|
0
|
564
|
|
POST
|
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
09-02-2010
10:02 AM
|
0
|
0
|
2283
|
|
POST
|
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
09-02-2010
08:17 AM
|
0
|
0
|
1339
|
|
POST
|
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
09-01-2010
02:36 PM
|
0
|
0
|
1339
|
|
POST
|
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
09-01-2010
02:00 PM
|
0
|
0
|
2283
|
|
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
|
1339
|
|
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
|
1186
|
|
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
|
3063
|
|
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
|
1339
|
|
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
|
1665
|
|
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
|
1061
|