Latest Contributions by RichardFairhurst

You need to create an Event table with the RouteID and the measure.  You can optionally include a side offset field to make the points offset to the left or the right of the line as well.  Then convert the event table to a Route Event Layer, which will display the point generated on the fly in memory from those two fields.  Finally, export the Route Event Layer points to a permanent point feature class using the Data->Export menu item of the layer if you wish.  The permanent points draw faster, because they do not have to be processed in memory each time the map redraws. All of the points you see on the attached map snap shot are being created from an event table that defines each point location using the highlighted rid, meas and Distance fields in the table to define the Route it falls along, the distance along the Route to put the point and the side offset from the Route. ... View more

I have never processed a script on a service, only on normal SDE connections through Desktop, so this may be a restriction when you are using services. In that case, I have no solution for your problem if you are using services other than to run your nightly scripts against the Desktop SDE connection and replicate the result to the service.  All versions of python will always simplify all of your true curves when they operate on your geometry and you will see a change the in the area output from what you see in the area field.  Your only other option would be to permanently convert all of the polygons with true curves to high density N-gons to get both the VB Script and the Python calculations to return the same reported area shown in the shape.area field. So if this was all done against a standard Desktop SDE connection you could use a VB Script calculation in a nightly Python script, but the same is not necessarily true for an SDE service.  So the details of every aspect of your set up can be significant in determining the cause of the behavior and the different configurations of your data storage, software, database connections, etc. can all play a key role in the behavior of a given process. ... View more

I ran the following script using SDE under SQL server and it worked without error: # Import arcpy module import arcpy # Local variables: temp = r"C:\Users\RFAIRHUR\AppData\Roaming\ESRI\Desktop10.2\ArcCatalog\Trans Connection to SQL Server.sde\GDB_TRANS.TRANS.Test_Area" # Process: Calculate Field arcpy.CalculateField_management(temp, "ft", "[Shape.STArea()]", "VB", "") But I noticed that I have never had a field name called [Shape.area].  In my file geodatabase it is [Shape_area} and in my SDE database it is [Shape.STArea()].  But this could be a difference in the way my SDE administrator set my SDE geometry defaults up. The script is being run on a computer with an Advanced Desktop license install.  I have never used ArcGIS Engine license if that is what you are using.  You would have to pose your question to users of Engine if that is what you are using. This may be an installation option issue.  I also do not do ArcGIS installations, so if my IT staff enabled some option that lets my script run that was not enabled when your install was done, I would not know what option that might have been,  I only know that with Desktop installs there is a way to get VB Field Calculations to work within Python scripts. ... View more

If the VB version of the calculation works, go ahead and include it in the nightly script.  They work for my nightly scripts and I use VB in my Python script Field Calculations more than Python_9.3 or Python.  Here are examples of VB script Field calculations I actually use in my nightly Python scripts: Empty string assignment: arcpy.CalculateField_management(CENTERLINE_ROUTES_MERGED__3_, "ROUTE_ALT1", "\" \"", "VB", "") Numeric Value assignment: arcpy.CalculateField_management(CENTERLINE_EXTENDED_Layer__13_, "CENTERLINE_EXTENDED.TRANSFERRED", "1", "VB", "") Date/Time assignment: arcpy.CalculateField_management(SCRIPT_LOG_View, "FINISH_TIME", "Now (  )", "VB", "") Field data transfers in an unjoined table arcpy.CalculateField_management(CENTERLINE_ROUTES_MERGED__5_, "ROUTE_NAME", "[ROUTE_ALT1]", "VB", "") Field data transfers between joined tables arcpy.CalculateField_management(RDNUMBER_Routes_Layer, "RDNUMBER_Routes.First_STNAME", "[RDNUMBERS_ALL.FIRST_STNAME]", "VB", "") The calculation you are doing is in the Field data transfers in an unjoined table category and should work fine in your nightly python script.  I have found that only VB Script multi-line advanced field calculations are not supported in a Python script. ... View more

Flavor of SDE?  ArcMap version?  SDE database version?  How was the polygon geometry created?  COGO, buffer tool, parcel fabric processes? All such details can potentially play an important role in what you are observing. However, ultimately this question has to be posed directly to Esri, because the Field Calculator is a black box for everyone except for the developers of the tool.  All of the details above will be required to make the report. ... View more

There is no way anyone can help you or replicate what you are reporting without the specific calculation code you are using.  Please post your calculation.  Otherwise, if you are just making a general statement about calculation behaviors using the two languages then your observation is not true for any of the calculations I do. ... View more

No, that is not quite right.  I am saying that if B is in the field list of the update cursor then it will trigger all modified field value listeners it has set up as soon as the updateRow method is run for any given row, even if you make no change of any kind to the field B data for that row.  Including B in the field list always triggers the modified value listeners of field B and those listeners can only be stopped by excluding it entirely from the update cursor field list scope (since you should always intend to run updateRow as some point with an update cursor). Including field A in the field list or not including A in the field list has no effect if it is just a standard field that has no relationship class trigger/listeners. So go ahead and use an update cursor as long as you only access field A with the update cursor.  But the moment you let the update cursor have access to field B within an Editor session, you are firing the field B listeners every time you update a row, whether you thought you were making changes to field B or not with your code. I am mentioning this, because this behavior is not at all like an interactive Editor session.  Field B can be in a table view and you can click on the Field B value and copy it to your clip board, and you can change the value in any other field and save the edits without triggering the Field B listeners.  In an interactive Editor session only an actual change to the Field B value triggers the listener.  The update cursor behavior is the equivalent of the Editor always triggering the listener for the row your cursor was on just by opening Field B for viewing in a table view and pressing the save button.  Nothing else is required to trigger the listener when the update cursor behavior is occurring. ... View more

The real code that destroyed my annotation actually read the value in the field that participates in the label expression and then based on that value actually updated a field that did not participate in the label expression.  When the UpdateRow was called both fields were treated as modified, and the annotation was updated by the label engine.  That was unexpected, since I had made no changes to the value in the field that affected the annotation label expression, I had just read it. My further tests where I did not read or update any values in any field have just been designed to show that the behavior occurs as soon as any row is passed to the updateRow method that in any way includes a feature linked annotation label expression/SQL field in the update cursor field list, no matter what else you do or don't do with the cursor.  So my tests have shown that including code to read the field value or excluding code to read the field value made no real difference to the behavior, it was the fact that it was in the field list at all when the updateRow method was processed. In any case, it is only possible to do updates with an update cursor on feature linked annotation that fully avoids this behavior if you never ever include any field that participates in an annotation label expression/SQL in the update cursor field list so that is completely inaccessible to the updateRow method of the update cursor entirely. ... View more

It appears that the programmers of the update cursor believe that the behavior I have observed is intended, since they do not regard an update cursor in an edit session as needing to abide by the same rules as a normal interactive editor session.  So I have asked that this be treated as a documentation bug, because I do not believe that the documentation contains enough information for a developer to ever anticipate this behavior might occur so that they can avoid it.  This behavior is a severe gotcha based on my experience. So the conditions required to trigger this behavior and cause your feature-linked annotation to regenerate itself according to its label engine rules are: 1.  An Editor session has been started by the Python code. 2.  The Update cursor includes a field list that has one or more trigger fields in it related to the feature-linked annotation classes label expression or SQL definition. 3.  The annotation already exists and has been manually edited to override some aspect of the default label appearance for the feature being processed by the cursor. 4.  The updateRow method is used on the row object of that feature, whether or not anything else was done to that row. Feature Linked Annotation requires an Editor session to use the update cursor, so you cannot avoid it by not using an editor session. Ways to avoid it include: Prior to using an update cursor, run the data through a Search Cursor to read all of the fields that can trigger an annotation update into a dictionary that uses the ObjectID as the dictionary key (assuming that the ObjectID is not a trigger field).  While processing the update cursor access the trigger field values for the record currently being read from the dictionary to evaluate each row and only use updateRow on an update cursor field list that has fields that are not annotation trigger fields. Use the Field Calculator to duplicate the field values of the trigger field(s) into a new field(s) that does not participate in the annotation label definition and use that new field(s) in the update cursor field list. Duplicate just the features into a new feature class in a file geodatabase with any normal copying tool and preserve a unique ID for each record that does not participate in an annotation label expression that ties to the original source data.  Make all modifications using the fields that participate in the label expressions in this copy.  Use a dictionary and cursor to transfer the data through the unique ID field value and do not include any field that participates in a label expression in the update cursor field list when transferring the other updates to the source data. Bottom line is never include a feature linked annotation trigger field in connection with an update cursor, unless you intend to have the annotation label engine regenerate every annotation label associated with every feature processed by the updateRow method of the update cursor,  I suspect that Composite Networks would have the potential for the updateRow method of an update cursor to trigger its modified record update behaviors if fields involved in composite relationships are included in the update cursor field list, although I have not tested that and I do not know how much potential damage could occur as a result.. ... View more

The rectangle is not the Rectangle by Width in the Create Route tool, so your rectangle shown is not representative of what the tool used.  The Rectangle by Envelope is used and its upper left corner shifts enough southwesterly that coordinate B is the closest point on the set of lines,  And because point B has a gap between segment 7 and 8, it is the beginning of the route.  If segments 7 and 8 had no gap between them, then point A would have been used for the start. Also points A through E are more perpendicular to the Coordinate priority than they are parallel.  All lines that are perpendicular to a coordinate priority start in the middle of the set of lines if there is even the smallest gap between them.  Coordinate Priority Upper left is only predictable for lines that have their beginning point oriented between due west and due north.  The point you want to begin this line is oriented between due north and due east, which makes is a perpendicular line to the coordinate priority of upper left, so the tool favors the middle of the line over the ends if it finds any gap in the line set. This has proven true for thousands of routes I have created with the Create Route tool every weekend for years.  You must use topology to truly get rid of all gaps the tool can see that you cannot see.  The tool's behavior for Upper Left priority is consistently going to go to start at the middle of any set of lines that is oriented from northeast to southwest if a gap exists anywhere in the middle of the line set. ... View more

I don't know what your lines represent, but I know why the tool did what it did.  Position B is closest to the Minimum Bounding Rectangle upper left corner that is built with the Envelope Option, not by the Rectangle By Area or Rectangle By Width option.  The Create Route tool does not use a sophisticated rectangle like you have shown, it uses the simple Envelope rectangle for speed.  If you want to figure out what the tool will do, the Envelope Rectangle is the rectangle you have to examine.  Additionally, there must be a nearly invisible gap between the two original lines that are supposed to meet at position B.  You need topology to find and fix the huge number gaps your network will have if you did not use topology.  Topology would show you that you have two dangles at position B.  It is impossible to do correct snapping in a network without it in my opinion, because you will never see with your eyes all of the unwanted tiny gaps the Create Route tool sees.  Your coordinate priority is also perpedicular to the route, which is bad.  You should always use a corner that is more or less parallel with your route (in this case only lower left or lower right are the only predictable route start coordinates with the entire set of lines in the rectangle) Larger gaps can be allowed, but they have to be in line with the best position of the Coordinate Priority and the two closest lines cannot overshoot each other.  If the line the Create Route tool is currently assigning measures to goes further lower right than the end of the closest line, it will begin measuring from the far end of that new line at its lower right corner and come back up toward the upper left.  If on the other hand the closest point of the new line is further lower right than the end of the line currently being assigned measures then the gap is fine. If all the lines in the rectangle form one route you will never get a fully sensible set of measures using the Create Route tool with the Coordinate Priority option.  You have branches, which means the route is not simple.  My MMonotonicity calculation would show that the route is complex, because it would not have a value of 1 (Continuously increasing measures).  Once line sets are complex the Create Route tool does many more steps than simply find the perfect start position and apply measures in ways that you will want.  I would say that you would have to break these lines into about 5 separate simple routes to get sensible measures (The lines in alignment with each other between segment 8 and 16 would be one route and that route should be built from the upper right or lower left, because perpendicular coordinate priorities line upper left and lower right will have bad results. The line segment 3 by itself because of its branching with segments 6 and 16 and its gap and change in alignment relative to segment 10.  Maybe segments 10 through 22, if no gaps occur under your table view and you use the Lower Left coordinate priority, not upper left.  Segments 2 and 12.  Segments 1, 13 and 15, because the gap is in line with each segment alignment and the coordinate priority).  However, that is only a guess, because I would need to know what these lines represent and why they are assigned the same route ID to understand how to simplify them I assign a field with a coordinate priority value to my original lines and make sure my routes have the same internal coordinate priority, but adjoining routes may get a different coordinate priority to ensure the first line I want to start the route is the beginning line.  I select each coordinate priority field value in separate sets, build the routes using separate Create Route tool runs, and then append them together. Road networks on a grid lend themselves to coordinate priority route creation, but other route networks types may not.  River networks often have to use the Field Measure methods to build the measures in the correct orientation and line order, since branching is expected and complex routes have to be allowed. In any case, the Create Route tool makes no attempt to do complex analysis of a set of lines once they fail to comply with the few simple rules the tool attempts to apply.  It just continues to enforce the simple rules it was instructed to do on the complex line set, and complex gaps and branches in a set of lines using these simple rules will result in measures that will not make sense to a human observer. ... View more

It is not really clear what problem you are trying to solve.  Is it a problem of measure directions changing within a single route due to bad line topology and contradictory orientations of the input lines relative to the coordinate priority you chose?  Or is this a problem of inconsistent directions between multiple routes that you want to control better so that you can predict the compass direction of the increasing measures of each route? The Minimum Bounding Geometry tool can be applied to the routes to find out some aspects or overall route orientation, but it is not the entire solution. I do use this tool with the Rectangle by Width option to get the overall sense of the orientation of my routes.  But it only really works if the route was built correctly to begin with. I find that knowing the number of line parts that make up a route is the most important information, since single part routes are consistent within themselves.  Single part routes only cause issues between itself and other routes for orientation issues and for them knowing the Minimum Bounding Rectangle is useful. Routes that have internally inconsistent measures mess this up and only can apply to the routes that are made up of multiple line parts.  So calculating a PARTS field is important.  The Python field calculation for that field is: !Shape.partCount! The other field that is important for finding and fixing routes with internal measure problems due to branching or looping is MMONOTONIC, which tells if measures continually increase or if they are internally inconsistent within a single route.  This value is also reported by the Identify Measure tool, but having it in a field is more useful for analyzing your whole route network than trying to use that tool one route at a time.  The MMonotonicy values and their domain translations are: 1 = Strictly Increasing 2 = All Measures are Level 3 = Increasing with Levels 4 = Strictly Decreasing 5 = Increasing and Decreasing 6 = Decreasing with Levels 7 = Increasing and Decreasing with Levels 8 = All Measures are NaN 9 = Increasing with NaN 10 = Measures with Levels and NaN only 11 = Increasing with Levels and Nan 12 = Decreasing with NaN 13 = Increasing and Decreasing with NaN 14 = Decreasing with Levels and NaN 15 = Increasing and Decreasing with Levels and NaN This field can be calculated with the field calculator with this Python calculation: Parser: Python Show Codeblock: Checked Pre-Logic Script Code: def MMonotonicity(feat): partnum = 0 # Count the number of points in the current multipart feature partcount = feat.partCount pntcount = 0 mmonotonicity = 0 lastM = -100000000 # Enter while loop for each part in the feature (if a singlepart feature # this will occur only once) # while partnum < partcount:   part = feat.getPart(partnum)   pnt = part.next()   # Enter while loop for each vertex   #   while pnt:    pntcount += 1    if lastM < pnt.M and lastM != -100000000:     mmonotonicity = mmonotonicity | 1    if lastM == pnt.M and lastM != -100000000:     mmonotonicity = mmonotonicity | 2    if lastM > pnt.M and lastM != -100000000:     mmonotonicity = mmonotonicity | 4    if not pnt.M:     mmonotonicity = mmonotonicity | 8    lastM = pnt.M    pnt = part.next()       # If pnt is null, either the part is finished or there is an    # interior ring    #    if not pnt:     pnt = part.next()   partnum += 1 return mmonotonicity Expression: MMonotonicity( !Shape!) ... View more