Latest Contributions by RichardFairhurst

‎02-13-2018

I cannot access the image you linked, so I don't know what the map looks like.

‎02-11-2018

There is nothing generic about what you want to do, as this request has no obvious basis in standard relational database manipulations. It requires a completely custom solution that will only apply to your data and thought process. It can be done, but you would have to elaborate on the rules and the full nature of your data to get a solution that works for more than this one example, since a manual solution would be my recommendation if this example was your actual complete data set. There are several problems that have to be solved or rules that have to be understood. 1. There is no reason to assume that the features in FC1 are ordered in the sequence required to directly match FC2 as they are read, so the solution must overcome disorder in FC1. 2. Are the features in FC1 uniquely related to just one feature in FC2, or can the value in column one for any single feature in FC1 be found in the list of columns for more than one feature of FC2? 3. Are there two or more features in FC1 that have identical values in column 1? If so, how do you want them matched to FC2? 4, Is the list of columns in FC2 always alphabetically ordered according to alphabetic sorting rules? 5. Do you really need the letter stripped off after the first position in the list in column 2 of the output of FC2, or is "T1,T2,T3,T4" an acceptable output for FC2 column 2? 6. Is there always only one letter that is always "T" at the beginning of each value in column two of FC1 that has to be stripped off if it falls after the first position in the list of column 2 in FC2? Or are there other letters at the beginning of the values in FC1 column 2 that need to be retained if they differ from the item that precedes it in the FC2 column 2 list? 7. Is there a spatial join component to the problem where the features that are matched have to be in some proximity of each other in FC1 and FC2 before the column one values are related? Other issues may become apparent as you explain your data and the rules governing a solution more fully. In general, the solution will be through a python script that uses cursors and dictionaries or lists to read and manipulate the data from FC1 prior to being outputted to FC2. But the order of operations depends a lot on how you answer the questions above and any others that come up as you give more details on your problem.

‎02-08-2018

While this still involves creating a new feature class to replace the original, at ArcMap 10.5.1 you can now use the Spatial Join tool to reorder the fields using the up and down arrows. You can also add completely new fields with the PLUS arrow and insert them in the order you want them to be stored using the arrows. You can even populate the new fields from the fields of your original feature class or the spatially joined feature class. The tool field view also lets you rename the fields. The only restriction in renaming fields involves trying to rename one field while at the same time trying to give another field the name that the first field originally had, since the tool will cross-link the data or otherwise get confused. You can also use the Spatial Join field view properties to change the field type, Null rules and field lengths of your fields, including shortening the field length, provided all of your data is compatible with the new field set up (i.e., the tool fails if any value cannot automatically convert and fit in the length and range of values for the new type, or violates a rule prohibiting Nulls). As long as you use the keep all target features rule of the Spatial Join tool you can avoid adding all but two new fields to your original schema by using a join feature class layer with a definition query of OBJECTID < -1 and the visibility of all its fields turned off. In the end you just need to drop the Join_Count and TARGET_FID fields to get all of your features with only the original schema fields all permanently in the new order, with the new field names, types and Null rules. (The TARGET_FID field is actually very useful if you need to rebuild relationships that were dependent on the original OBJECTID values before replacing the original feature class). And you can use ModelBuilder to save the tool set up or export the tool set up to a Python script for easy reuse. Although I have not actually verified that it works with any other tool except the Summary Statistics tool yet, it is possible that other tools that have a field map now support these changes in ArcMap 10.5.1. If I find that it works for any other tools with a field map I will post back here with the tools that work.

‎02-03-2018

I work for an agency that maintains a Land Management System (LMS) for tracking land use cases, like subdivisions and permits, processed by our Planning and Building and Safety Departments. For 20 years our LMS system has been integrated with GIS based on the Assessor’s Parcel numbers entered by our users. The parcel shapes associated with these parcel numbers are used to transfer information from GIS into our LMS and to create GIS features representing our LMS cases. However, our reliance on Assessor’s Parcel Numbers alone has produced far from perfect results due to many factors. We recently replaced our LMS and now have a system that also integrates the Address Points feature class that my agency maintains. This will help us solve many problems for our new cases as we go forward, but we did not attempt to create a direct association of our historic LMS address data with our GIS address points during conversion. Fortunately I have found that there is third integration option for solving these historic LMS/GIS problems: Subdivision and Lot descriptions. When it applies, the Assessors of my jurisdiction enters subdivision and lot information that describes each parcel and normally my agency’s LMS users have entered the subdivision and lot number descriptions of the cases that fall on these parcels. I have been discovering ways I can efficiently apply this data relationship to dramatically improve my agency’s historic LMS case shapes on a large scale. This Blog will provide an overview of one of the processes I have developed for leveraging this data relationship where it exists to significantly transform my LMS case shapes in GIS. An example of what can be accomplished in an afternoon using my techniques is shown below. Case shapes based on original parcel numbers - 26,105 parcels countywide Case shapes based on subdivision and lot description parcels - 124,643 parcels countywide A Basic Overview of the Process Without going into a lot of detail, here are the broad steps I followed to transform the case shapes below that were created from parcels that existed at the time of application before the property was subdivided. None of the shapes below represent the true boundaries of the case applications. 1. For the Assessor’s parcel feature class, which must be within a geodatabase, I concatenated the separate fields that make up the subdivision and lot description or each parcel into a single field using a standardized description format 2. Extract the LMS case number and field(s) containing each case’s subdivision and lot descriptions into a file geodatabase table 3. For the LMS data select the sets of records that contain the most common forms of a subdivision and lot description from within a field that may contain one. 4. Calculate the subdivision and lot portions of the description into separate fields using Python parsing methods. 5. Summarize all unique values in the field containing the lot portions of the description into a new summary table in the geodatabase containing the LMS data. 6. Add the set of pairs of fields required to store all of the lot ranges that can be parsed from the original lot description and parse the range values into them. This is probably the hardest step, depending on the number of lot descriptions you have and the format variations you encounter. 7. Run a script (see the end of this post for the script code) that populates a new table stored within the LMS geodatabase with the expanded set of records required to populate a new field with each individual lot number defined in the ranges of every lot description field pair in the summary table. This step makes all of the time spend doing the previous step well worth the effort. 8. Summarize the original LMS case data into a new table using the Summary Statistics tool so that it only has one record per case containing the case number and the legal description fields added in step 4 at minimum, although you can include as many fields in the output that you want so long as they do not cause more than one record per case to be created in the output. 9. Make the summarized LMS case data created in step 8 into a Table view and join its lot description field populated in step 4 with same field contained in the expanded table populated by the script in step 7. 10. Export the joined LMS case data table into a new table stored in the same geodatabase as the parcel feature class. With ArcGIS 10.3.1 and above this will cause the case records to expand to cover all of the records required to describe each individual lot for all of the case subdivision and lot descriptions. 11. Add a new field to the export output of step 10 and calculate the concatenation of the subdivision name with the field containing the individual lot values of each record into a new subdivision and lot concatenation field. These concatenated descriptions must match the format of the Assessors subdivision and lot concatenation field populated in step 1. 12. Make the Assessor’s parcel feature class into a layer and join its concatenated subdivision and lot field to the new concatenated subdivision and lot field of the expanded case record calculated in step 11. 13. Export the joined Parcel features to a new feature class to expand the set of parcel features to cover every individual lot in every joined case. 14. Here is the final result. This is a true representation of the parcels and property each case actually should have covered. The outcome is an LMS case feature class that has features in the shape of each and every parcel that matched the lots described in the case’s original overall subdivision and lot description. The more cases I need to be process, the more efficient this process becomes. I have applied it to nearly 1 million LMS cases in an afternoon and created a parcel output that would have required approximately 5 years of man hours to manually enter all of them individually into the LMS system. Based on questions and requests posted to this Blog I will add sections to this post to give further details that explain how I approached any step I have listed . There is a great deal more I could say about each aspect of this process, but for now I will post these general steps as a template that can at least help me make the process even more efficient or automated in the future. Below is the script I use in step 7. from time import strftime print( "Start script: " + strftime("%Y-%m-%d %H:%M:%S") ) import arcpy sourceFC = r"\\agency\AgencyDFS\Tran\FILES\GISData\rfairhur\Layers\Plus_Conversion_Data\Plus_Conversion_Data.gdb\PLUS_LOT_FIELD" sourceFieldsList = ["LOT","START_1","END_1","START_2","END_2","START_3","END_3","START_4","END_4","START_5","END_5","START_6","END_6","START_7","END_7","START_8","END_8","START_9","END_9","START_10","END_10","START_11","END_11"] insertFC = r"\\agency\AgencyDFS\Tran\FILES\GISData\rfairhur\Layers\Plus_Conversion_Data\Plus_Conversion_Data.gdb\PLUS_LOT_RANGES_FULL" insertFieldsList = ["LOT","RANGE_COUNT","EACH_LOT","START_1","END_1","START_2","END_2","START_3","END_3","START_4","END_4","START_5","END_5","START_6","END_6","START_7","END_7","START_8","END_8","START_9","END_9","START_10","END_10","START_11","END_11"] arcpy.TruncateTable_management(insertFC) icursor = arcpy.da.InsertCursor(insertFC, insertFieldsList) countDict = {} with arcpy.da.SearchCursor(sourceFC, sourceFieldsList) as sourceRows: for sourceRow in sourceRows: for j in range(0,22,2): if j == 0 and sourceRow[1] == None: # print(sourceRow[j+1]) l1 = [sourceRow[0],0,sourceRow[0]] l = l1 + list(sourceRow[1:]) # print(l) icursor.insertRow(l) del l1 del l if sourceRow[0] in countDict: countDict[sourceRow[0]] += 1 else: countDict[sourceRow[0]] = 1 elif sourceRow[j+1] != None: # print(sourceRow[j+1]) for i in range(int(sourceRow[j+1]),int(sourceRow[j+2])+1): l1 = [sourceRow[0],0,str(i)] l = l1 + list(sourceRow[1:]) # print(l) icursor.insertRow(l) del l1 del l if sourceRow[0] in countDict: countDict[sourceRow[0]] += 1 else: countDict[sourceRow[0]] = 1 del icursor print( "Expanded Lot Records: " + strftime("%Y-%m-%d %H:%M:%S") ) with arcpy.da.UpdateCursor(insertFC, insertFieldsList) as updateRows: for updateRow in updateRows: updateRow[1] = countDict[updateRow[0]] updateRows.updateRow(updateRow) sourceFieldsList = ["LOT","RANGE_COUNT"] with arcpy.da.UpdateCursor(sourceFC, sourceFieldsList) as updateRows: for updateRow in updateRows: updateRow[1] = countDict[updateRow[0]] updateRows.updateRow(updateRow) print( "Set Range_Count field: " + strftime("%Y-%m-%d %H:%M:%S") ) print( "Finish script: " + strftime("%Y-%m-%d %H:%M:%S") ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎12-26-2017

By my count you have a list of 21 fields, so I am surprised you are not getting an indexing error when you try to compare updateRow[1:22]. Indexes are 0 based and the top index of the pair should be 21, not 22, if my count is correct. It should be updateRow[1:21] (you are skipping index 0 and therefore only have 20 items in the list, and since the final index has to be 1 greater that the last actual index, which is 20, it should be 21). Your tabbing also is hard to read. You should use the Syntax highlighter. Take note of the tabbing in the code below and make sure each tab level matches my code. In order for a compared record to be bypassed it must be an exact duplicate of the record in the other data source. Are you sure that all of the field types being compared are the same and that the fields in the two lists are perfectly matched up? For example, if one data source has a numeric field, but the field you are matching in other data source is a string, the record values would never match. You would have to make the value type of every field identical to the value type field you are matching before you could compare the records. Perhaps the easiest way to compare the records is to print them when the changeCnt is 0. For debug purposes I would rewrite the code to the following and compare the two records for differences, misalignment of comparison values, etc. Preferably you could also add a query to the update cursor declaration that would only return a record that you expected to have an exact match in the other data source. with arcpy.da.UpdateCursor(updateFC, updateFieldsList) as updateRows: for updateRow in updateRows: keyValue = updateRow[0] # verify that the keyValue is in the Dictionary if keyValue in valueDict: # compare record in the dictionary to the existing update table record if list(valueDict[keyValue]) <> updateRow[1:21]: # Comment out this if clause once you account for differences in the records. if changeCnt == 0: print(list(valueDict[keyValue])) print(updateRow[1:21]) break # A change has been made to the mailing address, owner names or both changeCnt += 1 # temporarily comment out updates until you can compare the records # for n in range (1,len(sourceFieldsList)): # updateRow = valueDict[keyValue][n-1] # updateRows.updateRow(updateRow) # print changeCnt‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Alternatively, you could rewrite the code to just compare a single field to see how many records update and then gradually increase the number of fields you are comparing until you discover the field that is mismatched or has values that differ in the two sources for every row. It you found a consistent difference (like " " vs "") you could standardize the gdb version to have the same format as the sde version. The structure of the code seems sound, so the most likely causes of the kind of bug you are experiencing are in the specific implementation for the data you are processing, like misaligned field lists, field type differences in the data sources, or value formatting differences in the data sources.

‎12-26-2017

I have removed that line. This code is a revised extract from a much longer script that had several other subroutines. I missed that line and should have removed it before posting the code, since it is not relevant to the code you need.

‎12-22-2017

Hillary: You have written your code to write to every record, even if nothing actually changed. To only write to records where the value has changed involves adding an if clause to compare the records and only write to those that are different. The simple examples provided here are only meant to show the core concept, not illustrate all of the variety of effects that can be achieved by adjusting the program flow and logic. Here is a portion of a program I wrote for my own needs that will only update records in the update table when they do not match the source table. The dictionary built in this example trims white-space characters from the source table, since the update table has no white-space padding, but the source table has white-space padding: import python # subroutine for trimming whitespace from the right side of a text field value. def stringCaseTrim(value): tempstr = value return tempstr.rstrip() GDB_PUB_TLMA_PARCELS_ASSESSOR = r"C:\Users\RFAIRHUR\AppData\Roaming\ESRI\Desktop10.3\ArcCatalog\GDB_PUB.sde\GDB_PUB.RIVCO.PARCELS_ASSESSOR" PARCELS_ASSESSOR_Layer = "Parcel_Assessors_Layer" # Process: Make Feature Layer (2) arcpy.MakeFeatureLayer_management(GDB_PUB_TLMA_PARCELS_ASSESSOR, PARCELS_ASSESSOR_Layer, "APN < 'RIVER' AND MAIL_TO_ZIP > -1 AND ZIP > -1", "", "OBJECTID OBJECTID VISIBLE NONE;APN APN VISIBLE NONE;FLAG FLAG VISIBLE NONE;MAIL_TO_NAME MAIL_TO_NAME VISIBLE NONE;MAIL_TO_STREET MAIL_TO_STREET VISIBLE NONE;MAIL_TO_CITY MAIL_TO_CITY VISIBLE NONE;MAIL_TO_ZIP MAIL_TO_ZIP VISIBLE NONE;HOUSE_NO HOUSE_NO VISIBLE NONE;DIR DIR VISIBLE NONE;STREET STREET VISIBLE NONE;SUFFIX SUFFIX VISIBLE NONE;CITY CITY VISIBLE NONE;ZIP ZIP VISIBLE NONE;HOUSE_SUFF HOUSE_SUFF VISIBLE NONE;UNIT UNIT VISIBLE NONE;REALUSE REALUSE VISIBLE NONE;PRIMARY_CODE PRIMARY_CODE VISIBLE NONE;SECONDARY_CODE SECONDARY_CODE VISIBLE NONE;MULTI_CODE MULTI_CODE VISIBLE NONE;TRACT TRACT VISIBLE NONE;ACRE ACRE VISIBLE NONE;RECORDERS_TYPE RECORDERS_TYPE VISIBLE NONE;RECORD_BOOK RECORD_BOOK VISIBLE NONE;RECORD_PAGE RECORD_PAGE VISIBLE NONE;CNTY_CODE CNTY_CODE VISIBLE NONE;LOT_TYPE LOT_TYPE VISIBLE NONE;LOT LOT VISIBLE NONE;BLOCK_NO BLOCK_NO VISIBLE NONE;SUB_NAME SUB_NAME VISIBLE NONE;CAME_FROM CAME_FROM VISIBLE NONE;TAXABILITY TAXABILITY VISIBLE NONE;TRA TRA VISIBLE NONE;LAND LAND VISIBLE NONE;STRUCTURE STRUCTURE VISIBLE NONE;OWNER1_LAST_NAME OWNER1_LAST_NAME VISIBLE NONE;OWNER1_FIRST_NAME OWNER1_FIRST_NAME VISIBLE NONE;OWNER1_MID_NAME OWNER1_MID_NAME VISIBLE NONE;OWNER2_LAST_NAME OWNER2_LAST_NAME VISIBLE NONE;OWNER2_FIRST_NAME OWNER2_FIRST_NAME VISIBLE NONE;OWNER2_MID_NAME OWNER2_MID_NAME VISIBLE NONE;OWNER3_LAST_NAME OWNER3_LAST_NAME VISIBLE NONE;OWNER3_FIRST_NAME OWNER3_FIRST_NAME VISIBLE NONE;OWNER3_MID_NAME OWNER3_MID_NAME VISIBLE NONE;SHAPE SHAPE VISIBLE NONE;SHAPE.STArea() SHAPE.STArea() VISIBLE NONE;SHAPE.STLength() SHAPE.STLength() VISIBLE NONE") sourceFC = PARCELS_ASSESSOR_Layer sourceFieldsList = ['APN','MAIL_TO_NAME','MAIL_TO_STREET','MAIL_TO_CITY','MAIL_TO_ZIP','HOUSE_NO','DIR','STREET','SUFFIX','CITY','ZIP','HOUSE_SUFF','UNIT','OWNER1_LAST_NAME','OWNER1_FIRST_NAME','OWNER1_MID_NAME','OWNER2_LAST_NAME','OWNER2_FIRST_NAME','OWNER2_MID_NAME','OWNER3_LAST_NAME','OWNER3_FIRST_NAME','OWNER3_MID_NAME'] # Use list comprehension that includes whitespace trimmming to build a dictionary from a da SearchCursor valueDict = {r[0]:([stringCaseTrim(value) if str(type(value)) in ("<class 'str'>", "<type 'unicode'>") else value for value in r[1:]]) for r in arcpy.da.SearchCursor(sourceFC, sourceFieldsList)} PARCELS_ASSESSOR_OWNER1 = r"\\agency\agencydfs\Tran\FILES\GISData\rfairhur\Layers\Plus_Conversion_Data\Plus_Conversion_Data.gdb\PARCELS_ASSESSOR_OWNER1" updateFC = PARCELS_ASSESSOR_OWNER1 updateFieldsList = ['APN','MAIL_TO_NAME','MAIL_TO_STREET','MAIL_TO_CITY','MAIL_TO_ZIP','HOUSE_NO','DIR','STREET','SUFFIX','PARCEL_CITY','ZIP','HOUSE_SUFF','UNIT','OWNER1_LAST_NAME','OWNER1_FIRST_NAME','OWNER1_MID_NAME','OWNER2_LAST_NAME','OWNER2_FIRST_NAME','OWNER2_MID_NAME','OWNER3_LAST_NAME','OWNER3_FIRST_NAME','OWNER3_MID_NAME','FREQUENCY','SUM_SHAPE_Area','pa_key','pa_key_1','pa_key_2','pa_key_3','pa_address_1','pa_address_2','pa_address_3','pa_zip','pa_notation','RELATION','CREATED','EFFECTIVE_FROM','EFFECTIVE_TO','DELETED','ORIG_FULL_CONTACT_ID','ORIG_ADDRESS_ID','CONTACT_ID','lms_key','IS_ACTIVE','ISBILLING','Temp_Contact_Name','TEMP_CONTACT_NAME_ID','ISCOMPANY','ISCONTACT','GLOBALENTITYNAME','FIRSTNAME','MIDDLENAME','LASTNAME','ADDRESSTYPE','COUNTRYTYPE','ADDRESSLINE1','PREDIRECTION','ADDRESSLINE2','STREETTYPE','POSTDIRECTION','UNITORSUITE','ADDRESSLINE3','CITY','STATE','POSTALCODE','COUNTY','COUNTRY','PROVINCE','POBOX','COMPSITE','RURALROUTE','ATTN','ISACTIVE','ZIP_1','PO_NAME', 'STATE_1'] changeCnt = 0 with arcpy.da.UpdateCursor(updateFC, updateFieldsList) as updateRows: for updateRow in updateRows: # store the Join value of the row being updated in a keyValue variable keyValue = updateRow[0] # verify that the keyValue is in the Dictionary if keyValue in valueDict: # compare record in the dictionary to the existing update table record if list(valueDict[keyValue]) <> updateRow[1:22]: # A change has been made to the mailing address, owner names or both changeCnt += 1 for n in range (1,len(sourceFieldsList)): updateRow[n] = valueDict[keyValue][n-1] ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ updateRows.updateRow(updateRow) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎11-25-2017

If you have an Advanced license you should use the Detect Feature Changes tool, especially if the lines have some common attributes like Street Name, The tool works fairly well, although it still requires a fair amount of manual checking to validate, but that is true of all conflation approaches with data like what you described. This tool does account for the line bearings, so generally its results will not include false matches of east/west roads with north/south roads.

‎10-30-2017

I assume you are not using the Sort tool to create a copy and just wanting to sort in the table view, since the Sort tool would reorder the records in the new output in a way that the ObjectID would serve as the position counter of each record. The Field Calculator will not respect any sort other than the ObjectID order, so you can only use the Field Calculator if that is the order you want and you just want to eliminate record gaps. For that calculation you need to use the Python Field Calculation below: Pre-Logic Code: rec=0 def autoIncrement(): global rec pStart = 1 pInterval = 1 if (rec == 0): rec = pStart else: rec += pInterval return rec Code Block: autoIncrement() There is no way to use the sort order of the Table View to order the records of a sequential number. If you want to sort the records on one or more fields in a way that does not follow the order of the objectIDs, the best approach is to create a Python script that loads a dictionary with a tuple of the values of the fields you want, including the ObjectID as the last field to ensure all records are unique. The dictionary can be sorted and then assigned values with sequential numbers based on the sorted key. Although a python script can be set up in the Field Calculator, I never take that approach since scripts are best if they are run in Idle or another Python interpreter. See my Blog on Turbo Charging Data Manipulation with Python Cursors and Dictionaries. Something like the following untested code may work: import arcpy sourceFC = r"C:\Path\SourceFeatureClass1" sourceFieldsList = ["SortField1", "SortField2", "SortField3", "@OID" ] # Use list comprehension to build a dictionary from a da SearchCursor valueDict = {tuple(r[0:]):0) for r in arcpy.da.SearchCursor(sourceFC, sourceFieldsList)} counter = 0 for item in sorted(valueDict.keys): counter += 1 valueDict[item] = counter sourceFieldsList.append("counterField") with arcpy.da.UpdateCursor(sourceFC, sourceFieldsList) as updateRows: for updateRow in updateRows: keyValue = tuple(updateRow[0:-1]) # verify that the keyValue is in the Dictionary if keyValue in valueDict: updateRow[-1] = valueDict[keyValue] updateRows.updateRow(updateRow) del valueDict‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

‎10-29-2017

What possible purpose is served by this type of join? If there is no relationship between the two tables (since you never match any of the records of Table A to Table B for any reason), why do you need this output? If it is a multi-field relationship I have a tool for dong that kind of match. It would help a lot to understand why you want this type of output before suggesting the best approach for accomplishing it, especially if in the end there actually is a relationship between the two tables that you are failing to tell us about.

‎09-24-2017

First of all I am currently using ArcGIS Pro 1.2.0, but will be upgrading to the latest verion by November 6. In this example I am creating a relate between the original source table and the route event layer that was derived from it. When I select an event and use the Related Data button to activate the relate from the event table, the original source table opens with the record that I expect selected. However, if I clear the selection in the event table and try to I go the other direction from the selected record in the source table to the event table I instead get the route feature class table opened and the route used by the event is selected, not the event itself. . ArcMap Desktop would not have selected the route when I use a relationship to go from the original source table to a related event table. Desktop would have opened the event table and selected the related event, which is what I want.. On closer inspection, it looks like the route event may be appearing under the tab of the source route feature class rather than the actual route, but this is confusing. The related result should appear under a tab with the name of the event layer, not the route layer. If I was simultaneously trying to look at the routes themselves in a table view for a different purpose, it is no longer clear what table view tab I would inspect them under. Even without that complication, it is just confusing to figure out which two tabs I should use to go back and forth between the events and the original table using the relate.

‎08-14-2017

Randy: You were right that I needed to include at least two additional xml files. I have replaced the upload of the tool again and included all of the xml files with the "Field Match Tools" file prefix. That should take care of the problem. Thanks for letting me know.

‎08-13-2017

Randy: I have uploaded the Python Toolbox for the 10.3 version again with the xml file, which I believe contains the sidebar help. I see the sidebar help when I open this tool on my desktop. Let me know if the new file fixes the problem.

‎08-11-2017

Randy: Thanks for trying out code based on my Blog. I wanted to mention that since I wrote my Turbo Charging blog that I discovered that a composite key in a dictionary does not have to be concatenated into a string and can contain multiple values of any field type if you cast the list of values to a tuple. This means that the dictionary tuple keys will sort according to the native data type rules of each tuple component value and each component that makes up the dictionary key can be directly referenced with a tuple index. My Multiple Field Key to Single Field Key tool uses a tuple dictionary key to create a single field value in two data sources that can be used to create a standard join and that will sort the same way that the set of original fields would sort, with an ascending or descending sort independently applied to each field. That tool also optionally supports string matching that is case insensitive and that trims white space from one or both ends of the string.

‎08-09-2017

In addition to Elevation beings stored in a Polyline Z, you can make it a Polyline ZM and store a numeric time index on each point in its M value. This lets you to create point or line segment events on the road based on time indexes expressed as a number and allows you to interpolate the time at any point along the line. Given any segment, you can calculate the speed of travel based on 2D distances. With some coding you can get speed values based on 3D distances. Alternatively the M value can store 3D lengths using my Add-In which allows you to use 3D distance measure values for any line segment event or for 2D line segments overlaid on the Route, Measures could also be used for battery power levels at each vertex, although the measures are unlikely to be unique or always ascending, which is typical for Route measures. Basically any numeric value representing any attribute of your points can be stored in the M coordinate of a Polyline M or Polyline ZM.

Online Status	Offline
Date Last Visited	‎07-09-2026 12:59 AM

My Ideas

Latest Contributions by RichardFairhurst

Re: I want to know wich of the tools can make a map like this one?

Re: A generic tool or model to write and combine the values of multiple fields on one other field

Re: Permanently Reorder Fields in Feature Class (SDE)

Using Subdivision and Lot Descriptions to Correct Land Management System Case Shapes

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Overlay two Line layers

Re: Increment Field in Sorted Table

Re: Append Table to End of Table

Re: ArcGIS Pro Relates to Route Event Layers

Re: Multiple Field Key to Single Field Key Tool - Relate Two Layers Based on More than One Field

Re: Multiple Field Key to Single Field Key Tool - Relate Two Layers Based on More than One Field

Re: How to Update AssetTypceCode at a time for all feature class

Re: Converting points to lines but maintaining attributes of the points.

Add Dynamic, Epoch-Aware Spatial Reference Support

Add a Bearing WKID System Parallel to Spatial Refe...

What Does ArcGIS Pro 4.0 Really Need To Be For Dev...

Re: Turbo Charging Data Manipulation with Python C...

Re: Turbo Charging Data Manipulation with Python C...

Addressing