Latest Contributions by RichardFairhurst

Richard, Many thanks for your help but I think we are talking about different things? I'm talking about this window: [ATTACH=CONFIG]28077[/ATTACH] If run the following code: Public Sub test()     Dim pMXDoc As IMxDocument     Set pMXDoc = ThisDocument     Dim n As Integer     n = pMXDoc.ContentsViewCount     Dim pContentsView  As IContentsView     For i = 0 To n - 1         Set pContentsView = pMXDoc.ContentsView(i)         Debug.Print pContentsView.Name     Next i End Sub It displays only the following names (so no catalog window): Display Source Visible Selection Source, Display, Visible or Selection are different current view states of the Table of Contents window.  This is the correct interface for what you want.  Refresh will refresh it after you modify the contents of the window. ... View more

You want to access the IContentsView.Refresh method.  It also has a shortcut through the IMxDocument.UpdateContents method, since most applications implement the IMxDocument interface as one of the first steps of drilling into the map.  Look at the Loading a Table example on this help page for one way to implement the refresh.  Same principle applies to removing a layer or table from the map.  You can examine the state of the current Table of Contents view through the IMxDocument.CurrentContentsView method. ... View more

I decided to construct two tables based on how I interpreted your set up would have to be in order for the calculation to work and used your exact posted calculation on it.  The calculation worked in Desktop. Here is how the data was configured: Primary table fields (any gdb compliant primary table name would work.  I have named mine "OrientationOfCar"): ID (Unique ID for the join) OrientationOfCar (text field to be calculated) Join Table fields (only a join table named "JOIN_CarData_RoadLinks" will work for this particular calculation): ID (Unique ID for the join) Orientation (text field) CompassA (double) Bearing (double) I have attached two screenshots of the joined tables before and after the calculation. If your configuration differed from this in any significant way that would be a problem.  For example, if Bearing was not in the join table but was in the OrientationOfCar table (which seems more logical to me than what I set up) that would be a problem.  If the OrientationOfCar field being calculated was in the JOIN_CarData_RoadLinks table, that would be a problem.  If the join order of the tables was reversed that would be a problem.  If the name of the joined table was not actually "JOIN_CarData_RoadLinks" that would be a problem. I also assumed you were running this in Model Builder.  I don't use VBScript scripts and at 10.1 I do not have the option to export Models to VBScript.  Only Model Builder models and Python scripts are supported at 10.1. Model Builder had no problem with this calculation.  I built a model to emulate what I did in Desktop and it ran fine.  A screenshot of the model is attached. I also assumed you knew that only Layers and Table Views, not feature classes on disk, can be the primary layer/table in a Join.  So before creating a Join the Make Feature Layer or Make Table View tool has to be run if the data is pulled from ArcCatalog.  You will note that the model I built uses the Make Table View tool before creating the join. I exported the script to Python and it also ran.  Prior to 10.0 the Python script export would have failed, because codeblocks using VBA were not supported.  At 10.0 and after codeblocks use VBScript, not VBA, and should work (at least they do now at 10.1).  Here is the Python script Model Builder created. # -*- coding: utf-8 -*- # --------------------------------------------------------------------------- # testVBScriptCodeBlock.py # Created on: 2013-10-05 12:40:22.00000 #   (generated by ArcGIS/ModelBuilder) # Description: # --------------------------------------------------------------------------- # Import arcpy module import arcpy # Local variables: OrientationOfCar = "C:\\Documents and Settings\\rfairhur\\My Documents\\ArcGIS\\Default.gdb\\OrientationOfCar" JOIN_CarData_RoadLinks = "C:\\Documents and Settings\\rfairhur\\My Documents\\ArcGIS\\Default.gdb\\JOIN_CarData_RoadLinks" OrientationOfCar_View = "OrientationOfCar_View" OrientationOfCar_View__3_ = "OrientationOfCar_View" # Process: Make Table View arcpy.MakeTableView_management(OrientationOfCar, OrientationOfCar_View, "", "", "OBJECTID OBJECTID VISIBLE NONE;OrientationOfCar OrientationOfCar VISIBLE NONE;ID ID VISIBLE NONE") # Process: Add Join arcpy.AddJoin_management(OrientationOfCar_View, "ID", JOIN_CarData_RoadLinks, "ID", "KEEP_ALL") # Process: Calculate Field arcpy.CalculateField_management(OrientationOfCar_View__3_, "OrientationOfCar.OrientationOfCar", "CarOrientation", "VB", "Dim CarOrientation\\n\\nDim RoadOrientation\\nRoadOrientation = [JOIN_CarData_RoadLinks.Orientation]\\n\\nDim RoadCompass\\nRoadCompass = [JOIN_CarData_RoadLinks.CompassA]\\n\\nDim RoadCompassMax\\nRoadCompassMax = RoadCompass + 170\\n\\n    If RoadCompassMax > 360 Then\\n    RoadCompassMax = RoadCompassMax - 360\\n    ElseIf RoadCompassMax < 0 Then\\n    RoadCompassMax = RoadCompassMax + 360\\n    End If\\n\\nDim RoadCompassMin \\nRoadCompassMin = RoadCompass - 170\\n\\n    If RoadCompassMin > 360 Then\\n    RoadCompassMin = RoadCompassMin - 360\\n    ElseIf RoadCompassMax < 0 Then\\n    RoadCompassMin = RoadCompassMin + 360\\n    End If\\n\\nDim PointBearing\\nPointBearing = [JOIN_CarData_RoadLinks.Bearing]\\n\\nIf PointBearing > RoadCompassMin And PointBearing < RoadCompassMax Then\\n    CarOrientation = RoadOrientation\\nEnd if\\n\\nIf PointBearing < RoadCompassMin Or PointBearing > RoadCompassMax Then\\n    If RoadOrientation = \"-\" Then\\n        CarOrientation = \"+\"\\n    End if\\n\\n    If RoadOrientation = \"+\" Then\\n        CarOrientation = \"-\"\\n    End if\\nEnd if  ") So something you are doing is different from what I did. ... View more

Hi, I managed to solve the problem: - I checked for null values throughout the database but the database had none. I then decided to export the table with the join to the same gdb, just called it: 'JOIN2_CarData_RoadLinks'. This made the join 'permanent', my code then whizzed through and completed successfully. It would appear that you cannot perform comparative VBScripts using the field calculator on a joined table. Or at least my installation won't 🙂 Thanks again for your help, another 'bug' to add to the 'book of workarounds' 😉 Liam. Join calculations work and are the most common calculation I do.  GDBs are very good with them.  They have worked for 9.2 to 10.1 for me.  So it could be something peculiar to the complexity of the calculation or to the database configuration.  I have written if then logic for them, but I don't normally have as many conditions as your calculation included.  This particular calculation is more complex than most and has many failure points, null values being only one of them.  It is also not clear that you checked for an incomplete match of all records in the join itself, which would create join records with Nulls, or how much you broke the calculation down to its component parts to test each calculation step. You have a solution and workarounds are common in ArcGIS, but I don't want you or anyone else to conclude that VBScript join calculations commonly do not work.  They most certainly do work and I have never had to use a workaround for them.  So, as far as I am concerned, the probability is that the bug is in the calculation you wrote, not ArcGIS. Rereading your post I realize how ambiguous your description of your set up and objectives are.  I now believe that you may have used the incorrect Join table name in the calculation, since it looks more like an output variable, relationship class, or joined layer name than the names of the unjoined feature classes you actually have on disk.  You have to use the underlying feature class names of the original unjoined feature classes/tables on disk as the table names in Join calculations, not the name of the joined layer or table.  You should write this calculation with the Calculation editor and use it to insert all field names into the calculation.  I rely exclusively on the Calculation Editor for field names of joined data and never custom write joined field names into any calculation I compose when bugs like this appear.  I only custom write the comparative logic part. The other possibility is that you were trying to calculate values for one of the fields of the Joined table, not the primary table.  That is not allowed and is not a bug, it is by design.  Only fields of the primary table can be calculated in a join.  If calculating values into a joined field was what you were trying to do, that would explain why an export worked while the calculation didn't.  Once the feature class was exported the field you were calculating would be an actual part of the feature class itself and not in an externally joined table/feature class.  If calculating a joined field was your objective than the only solutions are to reverse the join order so that the field to be calculated is in the primary feature class/table or to export the feature class as you did. ... View more

This is has been extremely helpful.  Quick question as I am new to arcpy.  If I want to mark ALL repeated IDs with a flag and not necessarily just the second, third, fourth occurrence, how might I accomplish this?  For instance, if I had the following list of values: a b c d e e With the above scripts, I would get a-0 b-0 c-0 d-0 e-0 e-1 What I want is a-0 b-0 c-0 d-0 e-1 e-1 or 2 (Doesn't matter as long as I can see that this value is not equal to zero). My goal is to flag the values that are duplicates, identify the value and then assign a new value to those records.  If I split a polygon, for instance, I don't want to maintain the ID of the old one, I want to seek out the value and replace it with two new unique IDs. Thanks in advance. It makes no sense to use alphabetic unique IDs for an incremented value.  I won't write you the code to support it since with alphabetic IDs you are limited to meaningful values, which violates the concept of a unique ID.  If you are using an alpha ID switch it to a numeric unique ID as the only useful type for an autoincremented value. Personally I just use the Summary Statistics tool to get a count of the field I want to detect duplicates for.  I do a join, select for count > 1, break the join and then do whatever update process I want.  The Summary Statistics also can give me the highest value of that field to let me identify the next highest value.  It does not take much to do this manually. With a numeric ID, after getting the duplicate selection I would use the autoincrement calculation to begin with the next number and increment it.  Here is the autoincrement calculation: Parser: Python Show Codeblock: Checked Pre-Logic Script Code: rec=0 def autoIncrement():   global rec   pStart = 1 #adjust start value to be the next number in the ID series   pInterval = 1 #adjust interval value, if req'd   if (rec == 0):     rec = pStart   else:     rec = rec + pInterval   return rec Expression:  autoIncrement() However, with a numeric unique ID this whole process can be done as a standalone Python script.  This script does not sort the data, since IDs are meaningless and I want to gain the full speed of the da cursor, which will whip the pants off of any code based on the old cursor model.  It does process all records twice, but only updates records where duplicates occur.  It also always overwrites Null values with a sequenced number higher than any previously assigned number, whether or not there is more than 1 record that is Null.  (Deleted records at the end of the sequential ID series could cause previously assigned and removed IDs to be reused.  To correct for that set the "highest" variable to a value that will ensure no prior assigned numbers are ever used by the script). # Import the arcpy module import arcpy pStart = 1 # adjust start value, if required pInterval = 1 # adjust interval value, if required # Initialize the sequence number dictionary and the Route ID variables seqDict = {} ID = -1 highest = 0 changed = False # Assign data and field list variables. # Customize these variable inputs for your specific data myData = r"C:\MyPath\MyData.shp" fields = ["ID"] # Step 1 - Use an search cursor to get counts of the unique ID numbers rows = arcpy.da.SearchCursor(myData, fields) for row in rows:     if row[0] is None:         ID = "Null"     else:         ID = row[0]     if ID in seqDict:         seqDict[ID] = seqDict[ID] + pInterval     elif ID = 'Null':         seqDict[ID] = 2     else:         seqDict[ID] = pStart         if highest < ID:             highest = ID     del row del rows     # Step 2 - Use an update cursor to update all records with a count greater than 1 rows = arcpy.da.UpdateCursor(myData, fields) for row in rows:     if row[0] is None:         ID = "Null"     else:         ID = row[0]     if seqDict[ID] > 1:       highest = highest + pInterval       row[0] = highest       changed = True     if changed:       rows.updateRow(row)       changed = False     del row del rows If you really have to have an alphabetic unique ID, what is the increment style you propose to use?  Whatever increment style you want it involves much more code than it is worth to support it, which is why I won't write the code for you.  For that I would just do the Summary Statistics approach I originally suggested. After selecting the records based on the summary count being greater than 1 or having a Null ID value, I would update the alphabetic field manually to fit my style needs rather than doing the autoincrement calculation. ... View more

The first thing that comes to mind is that you may be failing to deal with Null values in the calculation.  Since this code involves a join, any record in the primary table that is unmatched in the joined table will have Null values passed to the calculation.  Nulls often generate this kind of error when comparisons are attempted in VB Script.  So you may need to add logic to the model to ensure that no Null value records get processed by the calculation or add IsNull checks to the calculation and ensure that a valid CarOrientation output occurs for those cases without comparing the record values. Other than that, my approach with these kinds of problems is to take the script intermediate results up to that point and use the actual feature classes/tables in Desktop to run the field calculation there.  I would cut out all of the code except for the first logical test and only process that to see if it generates an error, then I would paste back each additional test until I hopefully threw the error so I could isolate the part of the code that is responsible for the problem.  Tedious, but it usually works. ... View more

no worries mark - if you are working in arcmap then in the first instance I would just run the code line by line in the python window: http://resources.arcgis.com/en/help/main/10.1/index.html#//002100000017000000 you can then copy my code statement by statement into this, hit return after each line and see if it runs ok - you'll get red error messages if it doesn't which will help to resolve any issues - there might be a couple. when you have fixed all the niggles and run it a few times then you can save it as a python script, add to a toolbox and define your input/output parameters: http://resources.arcgis.com/en/help/main/10.1/index.html#/Adding_a_script_tool/00150000001r000000/ cheers Tim Tim: it looks like he wants you to rewrite the script to use an update cursor.  As far as I can tell, all your script does is read the table and print to screen, but he does not want that.  He wants it to actually change a field value somewhere and does not know how to adapt the script to do that.  I am not sure what field or table he wants to update, so I think he needs to provide more information about his end goal.  But I am sure he wants the script to actually do the update for him like a field calculation would. ... View more

To make a comma delimited number with no decimal places do this in a Python calculation: '{0:,.0f}'.format(Prev_Total) + ' boxes collected' ... View more

I'm not familiar with python and I have a basic question about simple field calculations in python rather than VB. This is needed because I have a model I am exporting to python for task scheduler. My model runs fine in ArcMap but when I run it as a python script it cannot complete the field calculation in VB expression form. Any help converting the following to a python expression would be appreciated VB Expression to convert (field is stored as float): [Prev_Total] & " boxes collected" -------------------------------------- This is to be calculated in a string field. Python would be: str(!Prev_Total!) + " boxes collected" ... View more

Harder to read though. I think you had it before, just needed to escape the ': exp = 'str(!NUM1!) + "\xb0 " + str(!NUM2!) + "\'"' The whole deal is kind of confusing because you have to write code that has to evaluate to a string that has to evaluate to code. I agree that the fix you suggest would work and is more readable.  I just prefer to use Model Builder to write the expression, because then I just have to write the equation, which is easier to read than anything I deal with in a Python script.  To get my output I just had to know how to write the expression: str( !NUM1! ) + "\xb0 " + str( !NUM2! ) + "'" Much easier to get correct than any of the python conversions to a string. ... View more

Thanks, but this is what I got: exp = 'str(!NUM1!) + "\xb0" + str(!NUM2!)' >>> arcpy.CalculateField_management("GISMainFabric_Line_Clip_0","Bear", exp,"PYTHON 9.3") ... Runtime error  Traceback (most recent call last):   File "<string>", line 1, in <module>   File "C:\Program Files (x86)\ArcGIS\Desktop10.1\arcpy\arcpy\management.py", line 3128, in CalculateField     raise e ExecuteError: Failed to execute. Parameters are not valid. ERROR 000800: The value is not a member of VB | PYTHON | PYTHON_9.3. Failed to execute (CalculateField). Well this one you should be figuring out, since it tells you in the error what the problem is this time.  You missed the underscore in "PYTHON_9.3" (You wrote "PYTHON 9.3") exp = 'str(!NUM1!) + "\xb0" + str(!NUM2!)' arcpy.CalculateField_management("GISMainFabric_Line_Clip_0","Bear", exp,"PYTHON_9.3") If you want a space between the numbers and the minutes symbol after the second number, the expression should be: exp = 'str(!NUM1!) + "\xb0 " + str(!NUM2!) + "'"' ... View more

try: arcpy.CalculateField_management("GISMainFabric_Line_Clip_0","Bear",str([NUM1]) + '\xb0' + str([NUM2]) + "'","PYTHON 9.3") He forgot the parentheses for the str method.  Above revision should work. ... View more

Hi, I am trying to split groups of points that intersect polylines, but I cannot seem to find a tool that can perform the task. I have performed a spatial join with a one-to-many relationship so that all of the points now have the [Roads.ID] value stored in [Points.RoadsID] field where they intersect. Here is a sample of my data: - [Roads] [Roads.ID] [Roads.Name] [Roads.Shape_Length] [Points] [Points.ID] [Points.RoadsID] [Points.Speed] What I would like to do is split the [Points] table up into groups of points that all have the same [Points.RoadsID] value so I can perform statistical analysis on them on a road-by-road level. Any help would be appreciated, Thanks, Liam. No need to split the output up.  Just use Summary Statistics with the RoadsID as the case field.  That will summarize the entire result into a single table of values that group on the RoadsID values.  Then use the Make Feature Layer tool, the Join Tool and the Field Calculator Tool to transfer the result.  You would join the original Roads and the summary output on the RoadsID field.  If you have multiple summaries on the RoadsID groups (which can be created with one Summary Statistics tool run) you still have to run the field calculator to transfer the results for each summary field separately. Alternatively use a Python da cursor, but that requires skill in understanding how to create a dictionary of summary values.  The #14 post in this thread shows a script for filling in a running count field and count summary field grouped by a case field using a python cursor and a dictionary.  More sophisticated summaries are possible using the principles of that script and it is possible to do many concurrent summary values (count, mean, min, max, std dev, etc) that output to multiple fields in just two passes (an aggregation pass followed by an output pass), similar to how the example does it with the unique numbering and count by group field.  The script could be adapted to do the aggregation pass on the points and the output pass to the Roads rather than doing both passes on the same feature class. Another suggestion is to create Linear Referenced Routes from your road lines (most likely by using Create Routes) and then use the Locate Features on Routes tool to create point events along the line rather than just a Spatial Join ID association.  That tool preserves the Point ID values like a Spatial Join, but also associates the points to a RouteID and a measure (station) position on the line and it tells you if the points fell on the right or left side of the line with the optional distance field.  I would calculate the original X and Y coordinates of the points into a pair of fields and then run the Locate Features Along Routes tools.  With this technique you can see exactly where each point fell on the line with the Make Route Events tool or menu item.  You can also calculate the new X and Y coordinates of the events on the line to see the offset in each plane.  The relative distances along the line between the points can be determined from the event data as well as the sort order of the points along the line from one end of the line to the other. LR events make the relationships between points and lines much more intelligent and permit you to do everything you would do with just the Spatial Join, plus much more.  If the RoadsID is for a grouping of road segments already, the Route can create a workable single line representation of the RoadsID from those segments which also makes working with the segment groups more intelligent.  Through geoprocessing it is possible to maintain an association between your original centerlines to the route representations so you only have to do updates to a single network.  The 10.2 Roads and Highways extension may also be worth considering, since you seem to be working in the Transportation field. ... View more