Latest Contributions by RichardFairhurst

I have no problem restructuring the code, but I need an example of what the input and output would look like to understand what you are doing.  The code portion you provided assumed I knew what had happened before it and I didn't.  I want to adapt the code.  I have already rewritten it twice to adapt it to my own data and needs with multiple fields and reduced the processing time down by 4 times.  Ultimately the more I do it the more likely I can create a generic structure that can be quickly adapted to many, many problems like this. So I am only bothered if you raise the issue and don't share the example data. ... View more

I agree that the tools suggested are potentially useful and can get unique points and counts, but the Delete Identical tool limits that method to only those users with an Advanced license.  My script works for all license levels. I built a model with the tools suggested and ran it on my test data.  I had to additionally run the Delete Fields tool on the Intersect tool's point output name field to be able to use the Join Rule with a delimiter on the name field I wanted from the Centerlines in the Spatial Join tool.  The model took a minimum of 9 minutes and 20 seconds to run on my test data (3 minutes and 38 seconds for Intersect, 3 minutes and 27 seconds for Delete Identical, 15 seconds for the Delete Field tool, and 2 minute and 0 seconds for Spatial Join). My script consistently takes 2 minutes and 15 seconds or less to get me the final product I want and provides me with the cul-de-sac/stubs I also want.  In that time it additionally creates X and Y coordinate fields and an XY concatenation join field that I find useful. Spatial Join can produce a joined name list, but it does not make the name list unique or sorted or tell me how many of each name there are at the point without a specialized script that would do further manipulation.  My script does it up front.  My script output allows me to find every "True Intersection with Branching" if I want to validate the locations that have three or more lines with the same name, but that also intersect with other names.  I also do not want intersections formed at Interchanges, so I do not intersect those lines in my network.  The model will place intersections where the ramps cross whether I like it or not, but my script won't unless I create the line splits. ... View more

The methods that rely on intersect and delete duplicate processes do nothing to distinguish pseudo-nodes from true intersections based on a attribute.  In other words if two lines with the same street name connect there will be a point at that location, just like if two or more different street names connected at that location.  But from my perspective if only one street name exists where these points are created, then it is not an intersection, it is a pseudo node.  The intersect and delete identical process will leave pseudo node points mixed with true intersections and not provide any way to separate the two. The script I have created deals with all line end points, and classifies them to distinguish the four main classes of points (true intersections, cul-de-sacs/stubs, pseudo-nodes, and branches). It retains all of the name attributes of the lines that made it up so that the cross-streets of each intersection can be searched.  True intersections are only useful to me if I can use them to search for the street names that connect at the intersection or evaluate the connectivity configuration at the intersection, since I use them primarily for search tools and street name/network topology clean up.  I rarely actually display them on a map. On the other hand, the cul-de-sacs/stubs layers is very valuable for road network map display purposes.  I integrate my script into an additional script process that maintains a cul-de-sac/stub layer that has another field that further classifies these points to distinguish true cul-de-sacs from stubs/topological errors.  It also inherits a maintenance status from the line it terminates.  I use those points to display cul-de-sac bulb symbols on my maps. An example of how the cul-de-sac layer can be displayed is on this page of the maintained road book‌ my jurisdiction maintains.  If a road line terminates with a black dot it is a maintained cul-de-sac.  If a road terminates with an open circle it is a public road cul-de-sac that is not maintained.  If a single road line terminates with nothing at the end it is a stub.  The extraction of cul-de-sacs/stubs is only possible when every end point of the network is analyzed, like my script does.  The additional script processes I have developed preserve the additional cul-de-sac/stub classification field and update the maintenance status of the points from the lines weekly so that I only have to examine and classify new points each week. ... View more

Jutta: The code you wrote makes no sense to me.  I would have to restructure the code from the beginning and not at the stage you have rewritten it to deal with 3 fields.  If this is all coming from one record the code probably can be written using one dictionary. I need to see an example of the data and the result you really want.  Is this data all in one table?  Are they from separate tables?  Are there Nulls that have to be excluded? The error is also dependent on the code your wrote that populates the dictionaries.  I also don't think you can write a for loop the way you have written it.  You cannot extract keys from 3 dictionaries at once.  You have to get the keys from just one dictionary at a time and verify they are in the other dictionaries.  Also, the dictionaries in the for statement do not match the dictionaries in the string concatenation statement. So give me a real example of what the input data would look like and what you want the output to look like for value 47991. ... View more

Jamal: Use the script I wrote in this second post of this Discussion to do this.  You need to customize the workspace, file names, the field that will act as your list of name/ID values that meet at the intersection points, and the coordinate concatenation format to match your coordinate decimal precision needs. It is much faster than my previous methods and combines all line ends into the set of unique points.  Each point contains a field that combines all name values (or other ID values) that meet at that intersection point into a list where each name/ID is unique and listed in sorted order for each point.  Other fields tell you the total line count and the line count for each name/ID in the list that meet together at the point. Every line end point is included in the output and there is a POINT_TYPE field to distinguish points that based on your name/ID field represent True Intersections (multiple names meet together), Single-Line End Points (only one name and one line ends at the point), Pseudo Nodes (there is only one name where two lines meet) and Branching Lines (there is only one name where three or more lines meet). It currently does not consider Z values when it creates the unique intersection points, but I could be persuaded to make it optionally output each unique XYZ intersection point location if someone out there asked for it.  If I get enough interest I will package it as an Add-In that would simplify the script input parameter customization process. ... View more

Give an example of what the date field currently contains and what you want it to contain.  If more than one field is involved explain how in an example. ... View more

da cursors require an Editor session set up the way you showed in your code for versioned SDE data and complex feature classes, like Feature Linked Annotation, Composite Networks, topologies, etc.  Simple feature classes that are in a shapefile/non-versioned geodatabase do not require an Editor session when you use a da cursor.  I never used the old cursors much, since they are so slow and the Field Calculator was faster.  I thought they behaved the same. ... View more

I can only say that my tests have proven to my satisfaction that one cause of inaccurate counts is due to Editor listener events related to Composite Relationship Classes, but that may not be the only cause possible. If he has any Editor extension enabled of any kind, it is possible they could result in a similar behavior without any relationship class being present.  I bet the key is that he always has done the UpdateRow inside an Editor session when he has observed the miscount. ... View more

Perry: The GlobalID field does not have to be in the field list, only a field that the Composite Relatinship actually responds to.  For example, if I had a Relationship Class set up like yours, and as part of the relationship class behavior any changes in a field called Name results in changes to the related features of the relationship class, then if Name is in the field list, any feature with actual related features is being processed by the cursor at least twice, once before the trigger is fired and once after.  Additionally those related features are changing in what ever way the Name field makes them change, even though the Name value did not change.  So manual overrides get destroyed. I know the cursor processes these features at least twice, but I did not check to see if it processes only two times no matter how many related features exist or one more time for each and every related feature. I believe the legacy cursor will behave the same way, but I have not checked.  If you can use the legacy cursor outside of an Editor session, then the behavior will not be triggered, since it requires Editor listener events to be active.  Or in my example, if I excluded the field Name from the field list and no other field in the field list was connected to a relationship class listener, then the UpdateRow method would return a correct count even in an Editor session, since the listener never would be triggered.  I think ObjectID or GlobalID could be included in the field list, since the update cursor does not attempt to update these values. ... View more

The UpdateRow action in an Edit Session (which you had to set up for a versioned feature class) fires all triggers for fields that respond to Modified edit events, like Feature Linked Annotation label expression fields.  Basically if a Composite Relationship Class exists with a listerner for any field that you included in the UpdateCursor field list.  Every time a triggers fires and causes an update elsewhere, it results in the same record being processed by the cursor twice, once before the trigger and once after. The reason it is not consistent is that not all records have a relationship to an actual feature in another feature class.  So features with no Feature Linked Annotation will only be seen by the cursor once, but features connected to Feature Linked Annotation will be processed twice.  Additionally, when a record is processed twice, changes are taking place someplace you may not expect, i.e., Feature Linked Annotation triggers rebuild the annotation based on the label expression every time the UpdateRow fires on the feature they are linked to if a field in their label expression was visible to the UpdateCursor.  So you are destroying most of the manual adjustments you probably have made to your annotation. I destroyed about 2/3s of all the manual edits ever made to my Annotation before I realized what was happening and had to restore it from a backup due to this behavior.  I have complained to Esri that this behavior is not documented and is not at all similar to how the Editor responds in an interactive Edit session.  They have not admitted it is a bug and will most likely post it in a blog no one will read rather than in the cursor documentation.  It is a huge gotcha for editors of Feature Linked Annotation. You cannot include any field in your update cursor field list that the Editor is monitoring for Modified Edit events through a listener that triggers a Composite Relationship class behavior.  Including the field in the field list and using UpdateRow while within an Editor Session on a feature is all that is required to fire the trigger, nothing else.  The trigger fires even if the cursor never directly reads the field's value or never makes any modification to the field's value. This does not happen if you can use the UpdateCursor outside of an edit session, but that is not allowed with Feature Linked Annotation Feature Classes, so in that case avoiding the Editor is not an option.  See this post as well. I mentioned that the double processing of a feature by the cursor in this situation is another problem for routines that need to count edited features, but was told I would have to log a separate issue to have Esri look at it.  Since I now will only use the UpdateCursor on fields that the Editor never listens to so that I never again destroy my annotation, I won't be triggering the double count behavior again either. ... View more

After thinking about your problem you are approaching it in a wasteful way.  You should run the Summary Statistics tool on the table with the RCS_X field as the unique case field (right click the RCS_X field header and select Summarize...).  Do any summary, for example First for Geology1.  If you output to a file geodatabase you can rename the field called First_Geology1 to just Geology1 in the ArcCatalog properties or just leave it.  (If you output to dBase the field will be trucated and I don't use those tables, so you have to deal with the output field name if you do). Then type all of the conversion values into the output table into the First_Geology1 (or Geology1 or whatever field) in an Editor session.  After stopping the Editor, you can join the summary table on the RCS_X field to the original feature class and use the field calculator to transfer the new field values you typed, i.e. [Sum_Output.First_Geology1] by calculating those values over.  When doing the join add the Field Index when prompted.  This will save you having to retype the formula over and over for each value in the table for each separate run of the field calculator and you won't have to add quotes or anything around the old or new values.  Just type the new values one time into the table and calculate once. ... View more

To make that expression work as a single line if statement it has to be written: If [RCS_X] = "C+S+V+Z" Then "CLAY, SILT, SAND AND GRAVEL" Else [Geology1] The Field Calculator requires a value for every record, including the records that do not meet the condition.  This will use the current contents of Geology1 for any record that does not contain "C+S+V+Z". However, if these are all of the letters you translate and all combinations of these letters are possible you could write an advanced statement like Parser:  VB Script Use Code Block:  Checked Pre-logic Script Code: MyArray = Split(Temp, "+") Output = "" Name = "" For i = 0 to UBound(MyArray)   Select Case MyArray(i)     Case "C"  Name = "CLAY"     Case "S"  Name = "SILT"     Case "V"  Name = "SAND"     Case "Z"  Name = "GRAVEL"     Case Else Name = MyArray(i)   End Select   if i = 0 Then     Output = Name   Elseif i = UBound(MyArray) Then     Output = Output & " AND " & Name   Else     Output = Output & ", " & Name   End If Next Expression:  Output ... View more

No official help is provided for your problem by Esri.  They don't support these relationships for any sizable datasets for all practical purposes.  Every user is on their own to come up with whatever they can after experimenting with their data for weeks.  All in memory configurations I have tried take hours for the tools to complete and are extremely slow at redrawing, so I have given up on them. At 10.1 the ability to duplicate the geometry over and over again with a standard join and an export to a geodatabase is the only solution that works for me.  The export time is minimal and the redraw time is fantastic.  I can save my company far more money by not wasting my time and or my user's time with slow performance and using up a fraction of the unused Terabytes of disk space that is on our servers to duplicate the geometry over and over. I doubt Esri has much else to offer, given that the geoprocessing paradigm supported by Esri practically always requires you to create a new derivative feature class with nearly every geoprocessing tool you use.  Using that paradigm I have created huge numbers of copies of the same geometry over and over to get anything done, like it or not. ... View more

I am in transportation and intersections define all of my reference points.  This is the way all of my users understand the road network and makes human centric interfaces possible.  My County DOT never uses mileposts on the roads we maintain, so positions that are defined relative to intersections are the most reliable way we have of describing features on our road network.  Collision reports from the state also use intersection descriptions and offsets to define accident locations. The fields I create make it possible to select or filter intersections based on their most common characteristics using standard SQL expressions.  Examine the map picture in my first post more closely and you will see that I have correctly symbolized the different intersection configurations (3-way, 4-way, etc.) with symbols that emphasize those characteristics (triangles for 3-way, squares for 4-way, pentagons for 5-way, etc. each with a distinct color). These intersection points and the ability to use SQL with these fields have allowed me to design applications that let a user find and zoom to any intersection (correctly spelled, which is crucial to our operations).   By applying linear referencing tools to these intersection points I am able to create segments of road between two intersections a user selects or based on offsets from one or more intersections using a compass direction and distance provided by a user.  Road segments are the basis of all the money we get for gas tax or that we spend on capital improvements. The intersection count fields help me quickly see and identify topology errors (which often are invisible if you just look at at the lines) or unwanted name changes and name branching, which results in bad linear referenced routes.  The sorted name listing and associated counts also help me find unwanted variant name misspellings where two lines connect. (i.e., 6TH ST and SIXTH ST).  With a bit of SQL I can easily select and locate the name variants that should not exist where roads intersect. Intersections typically also define block limits for addressing and being able to easily identify actual intersections and their cross-roads is useful for assigning the well defined address range break positions.  I can use SQL or a sorted table view to choose the cross-street names that define an addressed block and zoom to the limits of the set of lines that fall between those two points, even if there are many lines that make up that block. As a derivative of these intersections I also create a linear referenced event table that lists every pair of street names in every possible order at each real intersection location.  This event table makes it possible to sort the rows by cross streets for each individual road in their alphabetical or drivable order.  This table makes it even easier to find unwanted name variants or to match user data to the network and to create the road segments I mentioned.  Without this initial set of points that event table cannot be created.  As a follow up I will be redesigning my code to derive that event table based on the coding techniques I have used in this post. Intersections provide fundamental data that is essential to understanding and using a line network in my experience. ... View more