I created a model to plot a line for specified distances along a specified azimuth, then plot another line from the end vertice of that line for a specified distance in a perpendicular direction, then generate a point from end point of the second line. I used the “Bearing Distance To Line” tool to pull from a table that lists degree values to four decimal points (for example, 132.2458, 45.3789, etc.). The model seems to run fine, but the orientation of the automatically generated line is different from a manually generated line using the distance/direction function, even though the inputs are exactly the same. I thought maybe the projections were different for the two feature classes, but they are the same as well. I cannot figure out why this is happening or which result is more accurate, and was hoping someone might be able to help.
Solved! Go to Solution.
I was using WGS84 for both the feature class line I was editing and also the Bearing Distance to Line tool. I know the distance is hard to measure with the editor directions/length since the length units but its the difference in angles that is really quite different. I have the editor set to Direction Type: North Azimuth so they should be comparable right for the angles between the two methods?
The geodesic values apply to the length correct, but shouldn't the angle of the lines be the same between the two tools? The Bearing Distance to Line says "The angles are measured clockwise from North" and in the Editor if I choose North Azimuth, the help says "the azimuth of a line is the horizontal angle measured from a meridian to the line, measured in the clockwise direction from north" and the schematic looks like a compass. Below the two lines are both originating from the same point with a bearing of 297,the cyan line is delineated based on the Editor -Direction and the green line is the Bearing Distance to Line tool using that same starting point bearing, then specifying distance in miles with a rhumb line. Like I said I know the distance isn't comparable since WGS84 doesn't have measurable distance units when editing but I feel like there must be something obvious in my methods for such a big difference?
The cyan line is the 297 bearing using the editor direction function for editing/adding a line. The greenish line was created using that Bearing Distance to Line tool. Actually someone else put in that line and then I just tried the tool and got the very same results. If the bearing doesn't look correct in the Bearing Distance to Line tool output then why is that? The benefit of the tool when using WGS84 is being able to have it draw a line in miles whereas I'm not able to do that editing a line using direction/distance with WGS84 since decimal degrees is the units or is there a workaround. Shouldn't both of these line angles be the same? I'm working on a project that I know someone else used the Bearing Distance to Line tool quite a bit and it doesn't make me feel very confident in our lines if the angles are this far off in cases where the tool was used.
azimuth cases you should try from a point relative to north
22.5, 45. , 67.5, 90. , 112.5, 135. , 157.5, 180. , 202.5, 225. , 247.5, 270. , 292.5, 315. , 337.5
you should be able to ascertain where things are breaking down since this is nothing more than a circle increment by 22.5 degrees clockwise from North.
Kathy and Dan, I did speak at length with ESRI technical support about this issue. I went through three different levels of support and at the end the tech support analyst said that both outputs were correct. The difference, according to tech support, is that the editor tool draws lines using "planar" geometry, while the bearing distance to line tool draws lines in a "geodesic" geometry. The tools cannot at this time draw lines in the same geometry, so they will appear different. Tech Support said they would submit a request to the programmers for an "enhancement" to address this problem, which would be incorporated in some future update to the program. I just downloaded ArcGIS Pro 2.2.3, and it doesn't appear that they have fixed the problem in that version yet. I personally think this is a fairly major discrepancy; maybe if you reach out to ESRI we can get some momentum on the issue?
That's what I figured... It needs clearer documentation to that effect. In fact drawing a 'clock/circle' to show the distortion would help assess the angles relative to it