Latest Contributions by RichardFairhurst

Unicode is not a standard string of characters and you have to use unicode if you have non-English characters in your field.  Unicode has requirements that normal strings do not and is not supported by many string functions.  I don't use unicode strings and don't have time to research Python unicode requirements this week.  I also don't know if the ArcMap label generator has any issues with unicode (although it shouldn't if you get no error creating a label that just uses a field with Arabic letters as a normal label field). For now just let me know if it works when you change line 37 to: expression = labelKey Hopefully that works and will create an error only on line 41, which you should then be able to change to: expression += u'\n' + fieldValues[0] If an error continues at line 37 insert the following line before line 37 and report the value that prints in the Python window: print(labelKey) ... View more

Create Routes does not create fields with measures in them, nor does any other tool.  Create Routes creates coordinates with measures stored in the geometry of the line, just like the X and Y coordinates at every point that makes up the line. It is your job to create the From_M and To_M fields and calculate the M coordinates into them.  You would do the same thing if you wanted to have fields display the X and Y coordinates for the start and end point of the line (although, unlike the M coordinates, for X and Y coordinates there may be other tools that also can accomplish this task).  The fields you would create to store all of the coordinate types would all be double fields.  Below are sample coordinate fields for all the possible coordinate values of the points at the start and end of your polylines that you could create and the Python calculations you would need to run to populate them. Polyline From coordinate calculations: FROM_X field is calculated using a Python calculation of !Shape.FirstPoint.X! FROM_Y field is calculated using a Python calculation of !Shape.FirstPoint.Y! FROM_Z field is calculated using a Python calculation of !Shape.FirstPoint.Z! FROM_M field is calculated using a Python calculation of !Shape.FirstPoint.M! Polyline To coordinate calculations: TO_X field is calculated using a Python calculation of !Shape.LastPoint.X! TO_Y field is calculated using a Python calculation of !Shape.LastPoint.Y! TO_Z field is calculated using a Python calculation of !Shape.LastPoint.Z! TO_M field is calculated using a Python calculation of !Shape.LastPoint.M! ... View more

Have you ever used the Create Routes tool to aggregate your segments?  This tool not only joins segments together, it adds measure (M) coordinate values (M is store the same way that X, Y or Z coordinates are stored) to create M-Aware polylines based on several methods (frequently using line length).  If you don't have a set of M-Aware Route polylines you cannot use Linear Referencing tools like Locate Features along Routes. It is unclear what you mean by Aggregating lines.  Aggregating lines using tools like Dissolve that do not add M coordinates to polylines is not linear referencing.  Nor is just by assigning many lines a common value, but leaving them as separate lines. Each coordinate of the polyline is assigned a measure or M value.  In the simplest case, if you had a two point line with a starting coordinate with a measure of 0 and and ending coordinate with a measure of 8, if you split that line, the coordinate created at the split will interpolate the distance of that point between 0 and 8.  So if the split was at measure position 6, the line with a starting measure of 0 would now end at 6, and the line with an ending measure of 8 would now start at 6. I gave you the Python calculation to get these coordinates into a From and To field already, if your lines are M-Aware Routes.  Read more on Linear Referencing if you still do not understand what an M-Aware Route is, since they are the foundation of LR. ... View more

Are the lines that you split your M-Aware Routes?  If they are, then the split lines contain the measures at each line end that you are looking for.  In that case you just need to do a Python calculation on each line to get the From field using !Shape.FirstPoint.M! and to get the To field using !Shape.LastPoint.M!. ... View more

I am not sure what this error means.  There could be several possible things this is indicating.  So, line 37 needs to be simplified to do only the most basic label unformatted to see if the problem is caused by the formatting codes or not..  Please change line 37 to just be: expression = '{}'.format(labelKey) Let me know if this fixes the error for line 37 and if a new error appears on line 43, where more formatting codes were used.  Once a plain, unformatted label is created we can try adding back some formatting options. Are any Arabic characters that are not in the range of a standard ascii font included in the parcel field?  If the error persists it is possible the format method does not support the character set your data uses.  If that is the case and the error continues try changing line 37 to: expression = str(labelKey) If both of these still fail let me know some of the values stored in the main parcel field, particularly any values that are not made up of just standard English letters and numbers.  String functions may not work and I may need to research the equivalent unicode functions. ... View more

The addin attached to this reply as been built to work with ArcMap 10.3.  I have left the attachment to the original post as the version compiled to work with ArcMap versions 10.0 to 10.2.  If you have found this addin useful let me know or give this post a like. ... View more

You are apparently not aware that the indentation of lines in Python has to conform to the Python rules for code block levels.  Indentations are required to be at the same level for all lines that are at the same code block level, and certain lines of code, like if and for statements have to be followed by an additional indent level to form a new code block level controlled by those lines of code.  Indentation must be observed even by commented lines.  Python also requires all variable capitalization to be exact, otherwise you will generate errors or logic bugs in your code. rather than uploading your code to another website, you should post the code you have edited within your post.  It is easier to post on StackExchange, since you just have to highlight your code and press the {} button to make it format within a code window.  In GeoNet you have to press the ... button and then apparently choose the More and choose Syntax Highlighter.  Paste your code into the dialog and Choose Python for the format. Times New Roman should work if you are just listing a single field from your related table, since you do not need to have multiple columns of data align together.  If you want more than one field and any kind of table column formatting you would need to choose a fixed space font. I believe I have corrected the indentation problems, but I cannot test it with my data, so let me know if the error still appears and the line number it reports.  Do not attempt to alter or customize the label format of my code to your tastes.  Before you do that you need to see a working example of the original label format I created as a baseline.  Then you can modify that code to a new format after you are better able to understand the rules of Python. I changed the path to use the D drive, but I do not believe that the path is valid, since it includes User rather than a User name.  Please verify the full path in Windows explorer and match it exactly.  If you do not want to hard code a specific user name and instead need to have this part of the path adapt on the fly to the user name of the computer in use, then the code would have to be modified to use the os python module to obtain the user name on the fly. # Initialize a global dictionary for a related feature class/table relateDict = {} def FindLabel ( [ParcelBlockCommunity] ):   # declare the dictionary global so it can be built once and used for all labels   global relateDict   # only populate the dictionary if it has no keys   if len(relateDict) == 0:     # Provide the path to the relate feature class/table     relateFC = r"D:\Users\main\Documents\ArcGIS\ValuatedParcels_Objection.gdb\Owners"     # create a field list with the relate field first (ParcelBlockCommunity),     # followed by sort field(s) (ParcelNumber), then label field(s) (OwnerName_Arabic)     relateFieldsList = ["ParcelBlockCommunity", "OwnerName_Arabic"]     # process a da search cursor to transfer the data to the dictionary     with arcpy.da.SearchCursor(relateFC, relateFieldsList) as relateRows:       for relateRow in relateRows:         # store the key value in a variable so the relate value         # is only read from the row once, improving speed         relateKey = relateRow[0]         # if the relate key of the current row isn't found         # create the key and make it's value a list of a list of field values         if not relateKey in relateDict:           # [searchRow[1:]] is a list containing           # a list of the field values after the key.           relateDict[relateKey] = [relateRow[1:]]         else:           # if the relate key is already in the dictionary           # append the next list of field values to the           # existing list associated with the key           relateDict[relateKey].append(relateRow[1:])   # delete the cursor, and row to make sure all locks release   del relateRows, relateRow   # store the current label feature's relate key field value   # so that it is only read once, improving speed   labelKey = [ParcelBlockCommunity]   # start building a label expression.   # My label has a bold key value header in a larger font   expression = '<FNT name="Times New Roman" size="14"><BOL>{}</BOL></FNT>'.format(labelKey)   # determine if the label key is in the dictionary   if labelKey in relateDict:     # sort the list of the list of fields     sortedList = sorted(relateDict[labelKey])     # add a record count to the label header in bold regular font     expression += '\n<FNT name="Times New Roman" size="10"><BOL>Owner Count = {}</BOL></FNT>'.format(len(sortedList))     # process the sorted list     for fieldValues in sortedList:        # append related data to the label expression        # my label shows a list of related        # cross streets and measures sorted in driving order        expression += '\n{}'.format(fieldValues[0])     # clean up the list variables after completing the for loop     del sortedList, fieldValues   else:     expression += '\n<FNT name="Arial" size="10"><BOL>Owner Count = 0</BOL></FNT>'   # return the label expression to display   return expression‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Use my code.  The Esri code is going to run incredibly slowly, since it rebuilds the search for each label.  My code runs 10 to 100 times faster.  You are wasting your time with the code you have written. At the same time it is apparent from your lack of understanding of the error code returned that you are a novice in Python.  Therefore, it will be easier for me to ask you for the information I will need to revise my code for your particular data and make the modifications myself. Are you using Arcmap 10.1 or higher? What is the key field in the feature class? What is the corresponding key field in the related table? What is the path to the related table? What are the field names from the related table you want to show? If the is in Arabic, what is the name of the font you would use for uniform spacing? That is a start.  I may have more questions later.  Once you have a basic working example for your data, you will be responsible to learn python well enough to make exact customizations of the label format to meet your ultimate needs, using the example I provide as a baseline reference. Please respond to my initial code attempt on stackexchange to your parallel post arcgis desktop - Labeling a layer with the values of stand-alone table (that is associated to the layer with 1-Many rela…  ... View more

See my Blog called Creating Labels with Related Table Data.  This form of code can be used in the Label expression of your features.  The key trick is to load the related table into a global dictionary that is created from your related table and that is loaded only when the first label is being built.  All other labels simple use the previously loaded dictionary to do all data lookups. You need to change the field name in the FindLabel definition to be your lookup key field in the feature class.  The comments indicate the other key items you need to modify, such as the path to your related table and the names of the fields from your related table that are to be used by the label expression.  The order of the listed fields from your related table determines the sort order of the listed records presented in the label expression.  You would also need to modify the fixed text "Cross Street Count =" in the expression being built to fit your label fields. A good knowledge of Python and the label format options can allow you to develop a variety of different label expressions and label layouts that work for related tables.  The Blog presents a few different examples. ... View more

Assuming your routes do not measure gaps and all start at measure 0 you can create an event table in a few minutes that would create the segments for you.  First calculate a FROM field with 0, a TO field with (Python calculation) !Shape.LastPoint.M! to get the end measure and finally a TO_95_PCT field with !TO! * 0.95 to get the TO measure of the Route at 95%.  Then export the Table View of your routes to create an event table. You can now use the Make Route Event Layer tool with this event table with the FROM field as the FROM measure and the TO_95_PCT field as the TO measure of a line event to see every line segment you want and you will already know the 95% length values of every route in the table.  You can use this same event table to work with the last 5% of the line by using the TO_95_PCT measure as the FROM field and the TO measure field as the TO field for a line event layer.  If you export these events to create actual Polylines they will have the same geometry as your routes, so they should contain XYMZ coordinates (including the interpolated 95% measure and Z value). ... View more

So in reality there should be another table that stores just one line for each Claim number, which is where the draw down should occur.  The spatial join should have left the amount out of that table, since it does not get duplicated simply because it has proximity to multiple allocations.  Doing it the way you have done it obscures this and makes it unnecessarily complicated to track, since now you have to track a single amount duplicated many times for no purpose.  The claims being consumed would be its own dictionary and be the place where you should  track the consumption of claims, not the M:M spatial join table.  The Spartial Join table would track nothing and only be used to examine the possible combinations in order if they have not been eliminated by a prior transaction as recorded by the claims dictionary. The spatial join only provides possible links, but you are only accepting the first one encountered.   So in reality you are using a first value summary table with only a rare exceptional case requiring a secondary first summary table when an allocation is eliminated by prior claim values being processed.  This is the result you really want, not a true set of all possible proximate combinations.  In my mind the two separate tables of just claims and just allocations should be recording what really combined in the transactions you want to allow.  If the spatial join table is kept, at the end only the actual transactions of the first records should be kept and all other records eliminated.  Either way the table of unique claims records and the table of unique allocation records is the best place to track, validate and compare summaries of the combination table that included both needed and unneeded combinations of claims and allocations.  The claims table of unique records is especially valuable if at the end of the process most, if not all, of the claim numbers and amounts will only be associated to a single allocation and be processed on a single date, all of which is easily stored in a single record.  That is the simplest representation of what I think you really are trying to track.  The tables you design for this problem should contain the list of the transactions where at the end of the day they are represented in their most basic and easiest to understand form.  The claims table is where I see that being done. Your way of talking about math also seems confusing.  You should want to add the positive allocation number to the negative claim value, not subtract it.  Subtracting would result in a value that converts the allocation to a negative value and combine with the negative claim to make an even more negative value than either value taken separately.  I doubt that is how you want the math to work. Anyway, in consumption problems I always try to keep the consumed amount unduplicated.  That usually simplifies the problem considerably over trying to work with sets of unique values that are needlessly duplicated.  That is usually a bad relational design that unnecessarirlly complicates showing the user the real transactions that are taking place. Also, if the combinations are kept I still think that date stamps are important.  Shapes may change over time due to improvements in spatial accuracy or ownership changes/subdivisions, and knowing the dates when these changes occurred relative to the tranactions that have been proceeds is bound to be something that is important if at some point in the future you ever need to trace back through the transaction history.  Property having only one shape, billing entity and operational status that works for all eternity just won't happen. ... View more

I reread your script and see it is not a new table, but rather an new field that has not been taken into account by the script.  That field or a new field needs to be processed as part of the conditional logic that determines if a claim can be deducted.  If the table with the individual claims always has new claims appended to it and also will contain all previously processed claims each time you run the script you probably should add a Processed field to that detail table.  Then you can process an update cursor on the detail table that would use the Flag I set up in your dictionary to write back to mark the newly processed claims in the Processed field.  The new update cursor would run in a new loop after and outside of the current script loops you have set up.  Anyway there are a few ways to handle the check of the previously processed claims based on your table configuration. Anyway, can a claim number and deduction amount hit multiple lines in the table with the new field?  Are you dealing with a M:M relationship between the two tables or a 1:M relationship between the claim detail sorted table and the claim deduction table?  A M:M relationship greatly complicates things and may require new fields and logic to properly deal with what you want.  All the code you have worked with so far assumed you are only dealing with 1:1, 1:M and M:1 logic, not M:M logic. I don't give examples of M:M logic in my Blog because the rules for processing those relationships tend to be very specific to the data being processed and it can is difficult to suggest code that works without first going through a full discussion of how those rules may apply.  The complications introduced by M:M relationships make them bad examples for demonstrating the principles of using dictionaries and cursors and should only be tackled after the simpler relationship types have been understood and the alternatives involving them cannot be used. For example, I have assumed the amount of RecClmNum 1010306 is cumulative in the top table and totals -28561.08 and has already been divided into 3 equal portions of -9520.36 for each of the three AlloCClmNums records shown, since that fits a 1:M relationship.  I have not assumed that the combined total of all three Allocation/Claim records is -9520.36 and the total claim amount is not cumulative and just being duplicated three times because there are three associated Allocations, which would cause the -9250.36 amount to have a M:M relationship in the two tables.  If in reality the total claim is -9520.36 then you need to tell me whether you want the script to divide that amount into 3 equal portions and deduct -3173.453... from each of the three AllocClmNums, or divide the amount and round to the nearest penny so that -3173.46 is deducted from one and -3173.45 is deducted from other two, or the full amount of -9520.36 is deducted from only the first AllocClmNum encountered and none of that amount is deducted from any of the other two AllocClmNums.  Another alternative in the case of duplicated totals would be to deduct as much of the claim amount as possible while still leaving 15000 in each Allocation and continuing to do that until the full claim is processed or some portion of the claim cannot be Allocated, in which case you would have to tell me how and where you intend to track the processed and unprocessed claim portions since the division pattern cannot be predicted or reproduced without knowing the exact order of every transaction (datetime stamps come into play in real accounting software for this reason).  You have to tell me what the total amount of each unique claim number is and what is to be done with each separate Allocation/Claim record to apportion that amount for the unique claim number in one of these ways (or in a way I haven't thought of) to make sure you get code suggestions that will actually do what you want. ... View more

I have gotten so used to Python not caring whether I use single quotes or double quotes that I forgot you cannot use single quotes with VB Script.  In VB Script you have to write the calculation with escapes.  The following works (determined by creating a model and exporting it to a Python script): arcpy.CalculateField_management("cmpl","Pipe_Material","\"CMP\"") Since this is not pure Python or pure VB Script it is not always easy to figure out where the Python parser of the script handles quotes and where the VB Script parser of the calculation handles quotes, so I usually build a model and export it to a Python script to get a reliable syntax. ... View more

See if hte code below make sense to you.  It is untested. with arcpy.da.SearchCursor(sourceFC_AllocClmsSpj,fields_AllocClmsSpj) as searchRows:    for searchRow in searchRows:       keyValue = searchRow[1]       if not keyValue in Dict_AllocClmsSpj:          lstRow = searchRow[1:]          lstRow.append(False)          # assign a new keyValue entry to the dictionary storing a list          Dict_AllocClmsSpj[keyValue] = [lstRow]       else:          lstRow = searchRow[1:]          lstRow.append(False)          # dictionary keyValue exists so append to the list          Dict_AllocClmsSpj[keyValue].append(lstRow) ...     Record[3] = True‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ... View more

Your reading of the first part of the dictionary assignment when a new key value is encountered in not fully correct.  You should read it as "if the actual value from 'AllocClmNum' (eg 1014397) is NOT in the dictionary, then assign 1014397 as a new keyValue that points to a list containing the list of field values associated with the record being read." The answer to your question is that for each additional record associated with an established keyValue I am appending to the list containing lists of field values the next list of field values for the current record.  So when the key 1014397 is first assigned to the dictionary that key points to this value: [[1014397,1010284,9520.36]] The next time key 1014397 is found it appends to the outer list the list of field values for the new record.  So [1014397,1010306,9520.36] is appended to [[1014397,1010284,9520.36]] to make it [[1014397,1010284,9520.36],[1014397,1010306,9520.36]].  When all 4 records are read the keyValue 1014397 will reference the following list of lists: [[1014397,1010284,9520.36],[1014397,1010306,9520.36],[1014397,1010328,9520.37],[1014397,1010285,7720.36]]  The list of lists is iterated to retrieve each list of 3 field values separately and then you are accessing the last field value in that list during each cycle of the loop. You can append to the inner lists as well, so you could add to each field record an initial flag value of False.  Then when you iterate the list of lists as each record meets your criteria for allocation you can set the Flag to True.  Then the list of lists would keep track of the records that actually altered your value and you would also know which records were skipped which did not alter your value, which you could use to assign a value back to the UpdatedRecipientClaims or append to a set of new tables that would show the transactions that occurred and the claims that were not processed. Note:  It is possible that rather than a list of field values you would get a tuple of field values from the table.  If that is the case then to append to the list of field values you would first have to cast the tuple to a list, i.e., mylist = list(tuple). ... View more