Latest Contributions by RichardFairhurst

Using a single Coordinate Priority will not work for all roads if any gaps exist between segment ends.  This is particularly the case for roads that are oriented diagonally opposite of the priority chosen (i.e., if priority is Upper Left and a road with gaps is oriented from upper right to lower left).  Any gap will allow a route to build in ways you don't want, so the best solution is to use topology and eliminate all small gaps that are not really supposed to be gaps.  The way the Create Route tool builds routes across gaps follows patterns that make sense to the algorithm, but not necessarily to the average user, so you have to validate them.  It is also not possible to correctly sequence routes that branch, so you have to create separate routes for each branch to sequence the segments predictably. By default I prefer to use Lower Left (standard engineering stationing orientation).  Then I use two calculations to determine if the route is simple.  The first is calculated into a field called Parts to determine which routes have multiple parts (gaps or branches), which is !Shape!.partCount.  All single part routes are simple and you don't need to check them.  All multipart routes need to be validated. The second is MMonotonicity, which is the calculation shown in this Blog.  This helps distinguish branched routes from routes with only gaps.  If Routes only have gaps and no branches they will report as more than 1 part with strictly increasing measures.  For those routes I look for diagonal routes that are opposite the priority I chose.  If a route is diagonally opposite of the orientation I chose I build it as a separate selection from one of the diagonal priorities (upper left or lower right if my default it lower left).  Since I always use the Measure Gaps option, I also add a From_Measure and To_Measure field to compare the length of the line to the maximum measure distance.  Measures that are much longer than the line length are usually unrelated roads separated by huge gaps or diagonally opposite roads that built from a gap in the middle out to one of the ends and then doubled back to measure the segments out to the other end. I have a Priority field that by default is "LL".  I select every segment with the "LL" value to build with Lower Left priority.  But if I determine some segments need to build from a different priority I may assign "UL" to those segments and use Upper Left priority on just those segments.  After I build these separate selections with different priorities I Merge the Upper Left routes together with the Lower Left routes I built by default at the end. Branched and circular routes will have more complex measure patterns that are not Strictly Increasing (MMonotonicities greater than 1).  Each branch off of the main route gets a separate RouteID that is related to the main route ID so that it is sorted immediately afterward.  These lesser branches are generally not used as often as the main route or are in jurisdictions I don't work for.  By splitting off the branches I aim to get the longest possible single main line route with Strictly Increasing measures that are logical, and one or more lesser branch routes that are not as crucial to my analysis.  Completely circular routes are never built correctly by the Create Route tool.  I always create two routes to break the circle apart and don't bother rejoining them.  Circular routes are always a special case and difficult to resolve, so you have to decide your own preferences and how much work you want to invest to make sense of them when you encounter them. ... View more

You cannot use a relate or relationship class to do symbology of a 1:M relationship.  As far as symbolizing you have to convert the 1:M relationship to a 1:1 relationship.  This can be done either by using summary tools, or if you have ArcGIS 10.1 or higher, by putting everything into the same geodatabase, joining the features on one field, and exporting the features to create a 1:1 feature class. IF you are querying fields from only one data source in the relationship, then a relate works fine to select the records in the related feature class.  However, the methods mentioned in the first paragraph are the only efficient way to query fields that involve the combination of the two datasets.  Of course, both of these methods do not refresh if you edit the original data, so they constantly have to be recreated. If you are willing to use an Inner Join (only records that match in both data sources are visible) you can use the Make Query Table/.  But that tool does not refresh if you edit the original data, cannot be edited, and performs badly, so it sucks.  I always use the other methods I mentioned and never use this tool. For some queries and analysis you can use cursors and dictionaries to perform the join in memory and get results, but it won't generally help with symbology without creating a new feature class.. ... View more

My first response is as useful as your post of the problem.  It tells you nothing. If  you want a better answer you need to give more information.  What kind of problem are you having? Is the Project Tool failing?  If so, what error message do you see? Is it creating an output in the wrong place?  What does that look like (i.e., provide a screen shot)? Describe the data you are trying to project.  Provide the operating system of your home PC and your work PC.  What steps are you following to Project your data? ... View more

Nice to know. ... View more

Dan: I know nothing about the resources you are talking about.  How do I go about finding all of this ... View more

Do you have the pure Python code ready to release that would determine the areas of every polygon shape that exists?  If not, then I actually can't do that calculation in pure Python, since I lack the time, expertise or justification to my employers that would allow me to start the development of such code on my own. ... View more

Joshua: Thanks for the information about how Python interacts with ArcObjects.  With Python being a wrapper that would account for part of the reason that the Python calculation takes longer.  It is most likely that different programmers wrote methods for determining area during the various versions and rewrites of this software.  Complex shapes I am sure have several programmatic techniques for breaking them down to simpler shapes as well as choices for methods that can handle floating point accuracy differently for performance reasons.  Again, with the concept of Resolution and Tolerance understood by each programmer, all of the results are "correct" since they adhere to that requirement.  If a user is intolerant of differences below those amounts that means that they chose the wrong Tolerance setting, not that the approach the programmer took was wrong. ... View more

I believe the Geometry Calculator is using code developed in C, which relies on math libraries developed independently from those for Python.  As Dan mentioned, Floating Point Precision is impossible for computers to represent with infinite precision and every time you alter the order of any two mathematical operations you can encounter different data type conversions and handling, even down to the bit handling level. The Resolution and Tolerance settings of your data have been respected, and that is all that Esri has guaranteed you or your client.  There is no such thing as a setting for infinite Resolution and absolute Intolerance of rounding in the real world.  That is true for both computers and for Surveyors and their instruments.  No Surveyor would ever allow a provision in their contract that would let your client refuse to pay them because of differences in recorded measurements at these levels of precision.  They would reject any request by your client to even show them the measurements that their instruments may have recorded at these levels, since they know that they are inherently unreliable. The Surveyor, like Esri, only guarantees their reported measurements to a certain Resolution and Tolerance.  Unfortunately, giving the actual computer data to a client is like giving the unfiltered survey instrument measurements to a client, you have no way to prevent an untrained client from expecting the tool to perform far beyond its actual capabilities.  Your expectations are not in line with the reality of computer science or real world GIS. ... View more

To my knowledge there is no way to make that a default behavior of the attribute table window. ... View more

Duplicate events will be returned for points that fall on the concave side of a curve in a route when the point falls at the radius origin for the curve and the curve is within the search radius and is nearest to the point.  That is because all positions along the curve are exactly the same distance from the point for that route.  The tool returns all of the events that are the same offset distance for that route along the curve, because it does not know whether you prefer the beginning of the curve, the end of the curve, or at any of the points between (and it would take another step for it to decide to favor any of these options).  I usually summarize these events and take the event with the lowest measure, although the mean or highest measure are equally valid. ... View more

if the data source is a file geodatabase you can use Select By Attribute with an SQL expression like: CAST(ROUTE_TYPE AS FLOAT) > -10000000 Unfortunately this does not work with shapefiles, and I could not find help showing a similar method for that data source.  But I highly recommend that everyone convert their shapefiles to a file geodatabase for its superior performance and many other enhancements.  SDE data source types may have alternative methods of casting. ... View more

If you don't have shared fields between the two datasets, how do you expect to build a Network Dataset? A Network Dataset without a set of fields that apply to the entire network to control things like route naming and evaluators is not going to be very useful. ... View more

You do need to use the Merge tool.  The Network Dataset will not Planarize the lines for you.  To Planarize the lines with a geoprocessing tool you can use the tool that Devdatta Tengshe points out in his response to this post​: "The Feature To Line (Data Management) geoprocessing tool can be used for 'cleaning up' the data. The help file mentions: Where input lines or polygon boundaries touch, cross, or overlap each other at locations other than their start and end vertices, they will be split at those intersections; each of the split lines will become an output line feature. If an input line or polygon boundary is not intersected by another feature, its entire shape will still be written out as a line feature. In Addition, remember to set the Preserve attributes option to true, in order to preserve the attributes in the output file." Also the comments by ccn and fmark point out that: "This is the most efficient option, and you can go a step further when you set an appropriate cluster_tolerance to 'correct' minor undershoots and overshoots in data, too (but be wary that the tolerance value doesn't simplify the data beyond useful spatial accuracy)" - ccn "Its worth adding that if you want to do the cluster combining as a separate step you can use the Integrate tool." - fmark If you have ArcMap 10.3 you should also look at the Conflation Toolset in the Editing toolbox.  The Generate Edgematch Links and Edgematch Features tools may be of particular use.  The other Editing toolbox tools can also be useful if you don't want to use a geodatabase topology. ... View more