nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Find more posts tagged with

Needs Clarification

Status: Needs Clarification

Comments

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?

MizukiKayano2

Thanks @AmirBar-Maor . We appreciate the feedback and consideration of this idea. We will explore the attribute rule options internally.

(The blunders come from edits done by us - such as using Align Features, or entering COGO values after creating lines, and not the digital submission process.)

Hedstrom_Jeff

@AmirBar-Maor this attribute rule you are referring to (DIRECTION MUST MATCH WITHIN), would it only apply to lines you are creating or is it a validation rule you can rule against lines you are looking to put through LSA? This rule is not in our parcel fabric as I am not sure when this type of rule was implemented as as system attribute rule. You know our situation that S&P Global migrated our parcel fabric from the ArcMap version back in 2022. Thank you in advance.

AmirBar-Maor

Hi @Hedstrom_Jeff

The Attribute Rule I mentioned does not exist. It needs to be a calculation rule. The parcel fabric assumes that the direction of the line (geometry) and the COGO direction match each other.

If one is +- 180 degrees to the other (+ some tolerance), the calculation rule can either flip the geometry or flip the COGO direction attribute.

Which one is would you flip? (geometry or COGO direction)

I can help with creating such a rule

Hedstrom_Jeff

@AmirBar-Maor in most cases, the line was drawn in the wrong direction for what the COGO says. As you know, S&P Global imported millions of parcel lines into the parcel fabric when we migrated to the ArcGIS Pro parcel fabric and "occasionally" lines were imported to the wrong to & end points. I have a field that detects these inverse parcel lines that I run on a selection when I go to do a LSA. I just run this script on case-by-case basis, because there would be thousands of lines to fix if I applied some sort of calculations and I am not 100% sure if fixing the geometry of the line on all of them would be the appropriate fix, more than likely it would be for most lines.

I can add this as a topic for us to talk about at our June meeting. Thanks Amir and have a good memorial day weekend!