Enhance the Weighted LSA tool to handle 180 degree flipped lines

[MizukiKayano2]

In our Organization, we often run Weighted LSA to check the integrity of data. We sometimes run into an issue (described in detail below) that we would like to request be handled with enhanced logic to the Weighted LSA tool. 

In our workflow, we receive linework from surveyors, and after we perform some clean up activity (such as adding any missing lines), we Create a Record and "Copy Lines to" to our parcel fabric to build the fabric.

In the following example, 0.609m line was missing from the surveyor submission, so I created the line by digitizing left to right (in the direction of 50-46-41). I used "Update COGO", but since it updated to a value few seconds off, I decided to copy the attribute from a nearby line which I knew to have the same bearing (230-46-41) and pasted into the direction of the 0.609m line.

Once the lines were in the parcel fabric, I ran the Weighted LSA, and got a High Rigorous Sigma Zero value. The Analysis layer showed how the ends of the line would move, which is when I noticed the 180 degrees "flip".

After I used the "Simplify by COGO" on that line, which flipped the line geometry to match the COGO value, I ran the Weighted LSA and got a Low Rigorous Sigma Zero value.

What I'd like to suggest is that the Weighted LSA tool handles these types of "flipped line" without user intervention.

Lines are not always digitized in the same direction as the COGO value we enter (e.g. when Create Features is used instead of Traverse, or when we manually enter COGO values after the lines are created). It would make our life easier if Weighted LSA took that into consideration; that 180 degrees difference between the line direction and COGO direction is the same thing.

[AmirBar-Maor]

Do you use the attribute rule 'DIRECTION MUST MATCH WITHIN' that is shipped with the parcel fabric before running LSA?

What would be the tolerance to consider a line as 'flipped'? (+-180 +???)

[MizukiKayano2]

Hi Amir,

We have the rule off because there was a concern it would catch too much. We will test in the dev environment after modifying the rule to catch a different range.

However, the request for enhanced logic still applies, as what I would like to have is the LSA tool to see two COGO values that are 180 degrees different (90 vs. 270) as the same thing. 

[ThomasHoman]

Rather than creating a new rule or widely opening the DMMW rule, would it be acceptable to have the LSA flag for review and manual/autocorrect the direction of the data if 180 deg case was observed?

This would unburden LSA from continually managing/nagging the problem line long term and allow DMMW to be kept to a minimal value.

Just a thought.

Tom

[AmirBar-Maor]

@MizukiKayano2 

One of the uses of LSA is to detect blunders. Having the wrong geometry, even when flipped, is wrong, and ignoring it can cause downstream effects in other areas. So it would be best to fix those bad geometries. 
What's the best way to correct the geometry by flipping them?

• Use the geoprocessing tool Flip Line
• Use an Attribute Rule (calculation) on the SHP field.

[MizukiKayano2]

Hi @AmirBar-Maor 

Thanks for the thoughts on this. While I agree the LSA is a useful tool to detect blunders, the problem is that when you have a flipped line, the LSA often cannot even process the data and the tool will fail to converge - so, then you have no analysis layers to help you detect where the mistake is. You can get around this by entering a very large convergence tolerance and force the tool to complete - but then the results of the LSA are so warped that the analysis layers still do not help you detect where the error is. This is something we have discussed with Tim before. His suggestion was a symbology layer or label expression to detect distance mismatches if you wind up with an LSA that can't converge. This is ok - but you have to apply this to each line layer, and in our case, we have 5 of them. So an LSA fails to converge, we apply 5 label expressions or symbology layers, we detect the error, we flip the line, then we re-run the LSA. That is a lot of steps....so I prefer @ThomasHoman's idea above, that the LSA flags the 180 degree flipped errors, or my original idea, where the tool handles this scenario completely. 

[AmirBar-Maor]

@MizukiKayano2 

LSA uses 'direction sets' as input so it's not that easy just to run a pre-process that flips lines.

If you have 5 wrong directions + a few true blunders I would not expect LSA to converge and as @TimHodson has suggested, it would be best to identify and fix those blunders before running LSA. Then you'll be able to catch the 'real' outliers.

A simple Attribute Rule calculation rule can detect and fix those blunders for you without any extra user work: the rule can either flip the geometry (SHP field) or add/subtract 180 degrees from the 'direction' (direction field).

Where do those '5 blunders' come from? I suspect from an external source like a digital submission process. If that is true - why not improve the digital submission process? You can either reject lines that have the wrong direction or fix them as they come into the system?