Select to view content in your preferred language

Implement a 'Post Processing' parameter in the 'Apply' tool to straighten parcel lines after a least squares adjustment

950
8
10-29-2024 11:21 AM
SeanLyons
Frequent Contributor

Our organizations utilizes the 'Weighted Least Squares Adjustment' tool, as well as the 'Apply' tool to apply the results to the parcel fabric. We are finding that in certain areas where we have a lot of 'point to edge' snapping, the results of the LSA are not ideal. After applying the LSA results, there can be a fair bit of warping so that the lines are no longer straight: 

SeanLyons_0-1730226012097.jpeg

From what we understand, this is a consequence of the “direction set” method for the LSA. Direction sets are created per record (plan). The new plan being integrated into our parcel fabric does not contain constraints for each of the points along the line, so the only measurements defining the original points is the underlying plan of lower accuracy. 

In the ArcMap world, this would have been straightened out with the 'Line Point Post Processing' parameter rolled into the LSA. In ArcGIS Pro, there is no such post processing parameter for point to edge scenarios. Our current workaround is to manually post-process the data by running an align features process where we draw a straight line from one end of the lots to the other and align everything to it. This can be time consuming, and we would like to request that a post processing parameter to straighten point to edge scenarios be implemented in the Apply tool in ArcGIS Pro - it could be an optional parameter, so each organization can choose the option that works best for them. 

Tags (2)
8 Comments
christinazhang2025

@SeanLyons  We would love this function migrate from ArcMap to ArcGIS Pro too. For the time being, would you try  Attribute Rules, something like a connecting lines that are straight in direction (180 degree internal angle) would not bend?  It's theoretical keen to know it works. I am not yet setup my env to test this. Thanks

AmirBar-Maor
Status changed to: Needs Clarification

Hi @SeanLyons 

I am going to ask some annoying questions in order to understand the business justification:

  1. If LSA moved data by up to 10 cm you would not notice it on the map - right?
  2. How much did the data move in the image you shared? Could it indicate that the data is of poor quality and should have never been adjusted to start with?
  3. Let's say you ran LSA and the maximal shift was 10 cm - what tolerance would you use to straighten up the lines?

 

We are dealing with 2 conflicting requirements:

  • Improve spatial accuracy - move the data to the most probable location.
  • Improve cartographic representation - the eye is sensitive to wiggly lines. Make it look better.

One has the potential of cancelling the other. And if you run around a block of parcels, making parcel road frontage straight, you will accumulate an error that is similar to traverse misclose. How should that misclose be distributed? 

 

SeanLyons
  1. This is dependent on scale and the area it is in. If this was a corner most likely not in the middle of a bunch of straight lines then yes
  2. Data moved about a metre. No the posting plan is in the correct location, the original data was of unknown accuracy and appears to not be correct. The modern posting plan is correct and that is where the lots should be located.
  3. I just want the lower accuracy lines to end up matching whatever the higher accuracy line says, even if the lower accuracy line only has topological links to the higher accuracy line. If that is a few metres or a few cm from where they started either is fine. Basically the same post processing that was using in Desktop to keep lines straight.

I want whatever the higher accuracy feature is to hold it's position and then the rest of the parcel spread the error out from the high accuracy line. As long as the higher accuracy line is holding in it's correct position and shape without bending then the error just needs to be spread out through the rest of the parcel as a whole. Whatever the old LSA engine in ArcMap did was fine. 

SarahSibbett

@AmirBar-Maor we love when you ask annoying questions, all good! I'm piggy packing onto Sean's comment, because I disagree that we are dealing with 2  conflicting requirements. The actual issue is that the adjustment needs additional constraints to preserve straight lines. 

The reason that the lines bulge during the LSA is due to a tension between the original plan 40m lines (which are actually 36.5m) and the bearings going east-west. The only constraint provided by the posting plan is an overall bearing across the 6 lots and the distance. This is not enough to hold the line along the six lots, which have distance accuracies of 1m and direction accuracies of 1 degree (COGO class 6).

SarahSibbett_4-1765913433579.pngSarahSibbett_5-1765913466155.png
The solution is to introduce direction only constraints into the posting plan. This is effectively what line points did in the ArcMap parcel fabric. This are added with the same COGO class as the posting plan (COGO Class 3), which sets the direction accuracy to 60 seconds.
 

This can be accomplished manually by activating the posting plan record, setting the connection line template to the relevant direction, COGO class, and direction accuracy, and adding intervening lines along the 6 parcels.

SarahSibbett_6-1765913522841.pngSarahSibbett_7-1765913541162.png

The direction-only constraints provide the necessary structure for the LSA to maintain the straight lines.

This is a manual approach, i.e., the direction constraints would have to be added manually during plan integration. However, it is possible to automate this and identify the intervening points along the line, since these are coincident with vertices along the long line (as long as topology has be validated). As a result, it should be possible to automate this process to add these direction only constraints given lines with more than two vertices, that are supposed to be two point lines. Curves could also possibly be handled, but it would require calculating deflection chord bearings along the curve to establish a similar direction-only constraint. This could be an optional 'Hold Straight Lines' checkbox on the LSA, perhaps? 

PS - yes, this absolutely has Dave H. written all over it. Feel free to e-mail us if you want to chat in more detail! 

AmirBar-Maor

@SarahSibbett 

While reading your reply I was thinking to myself: "Sarah really gets LSA. She must have taken some classes or she is spending too much time with Dave 😉 "... until I saw the last comment.

There could be multiple approaches:

  1. Introduce constraints within LSA.
    1. Providing different weights as proposed. At some point, if the distances do not fit, line will start bulging.
    2. We can also identify lines that have the same bearing before LSA and 'merge' them into a single line prior that will be used as input for the LSA , then decompose the on the way out. You can think of it as LSA filtering to  skelaton network. After LSA we can move the points using the parcel move point 'stretch' behavior.
  2. Post Processing - such a method could be applied to any data regardless of what caused the line to become wiggly (LSA, transformation (rubbersheeting), alignment, ...). Such a method could use the COGO direction to determine tangency or an offset tolerance.

I wonder what other customers like BLM need. @MikeZummo

AmirBar-Maor

@SeanLyons 

Did you try selecting all the lines with high accuracy (posting plan) as input for LSA?

SarahSibbett

@AmirBar-Maor - perhaps in January it would be worth a chat about this vs. messages back and forth? I'll set something up for you, me, Tim, and Dave. 

SeanLyons

@AmirBar-Maor I can select just the high accuracy plan and the line will stay straight but I want a holistic solution that doesn't involve me having to remember to select certain plans and not others. I still need to adjust the parcels under the plan as I need to select more than just the high accuracy plan to have the adjustment area make sense and produce a result that would be useful.