idea Calculated Area Should Account for LineString Boundaries in ArcGIS Parcel Fabric Ideas

Calculated Area Should Account for LineString Boundaries

MizukiKayano2 — Mon, 03 Nov 2025 22:06:06 GMT

In ArcGIS Pro, parcels bounded by LineStrings (used for natural boundaries) don’t have their calculated areas computed correctly.

For example:

This parcel is approximately 1,210 sqm according to the survey plan.
When part of a parcel (or all, such as an island) is built from LineString, the calculated area on the parcel is calculated incorrectly. This happens because the COGO distance on the LineString is calculated as the straight-line distance between the start and end points — ignoring the true shape of the boundary.
Our current workaround is to remove COGO from the LineString features, which results in no calculated area being displayed. While this avoids showing an incorrect area, it’s obviously not ideal.

Idea / Enhancement Request:
It would be extremely helpful if ArcGIS Pro could correctly calculate parcel areas that include LineStrings as boundaries — accounting for their geometry properly, rather than using straight-line COGO distances.

This enhancement would allow cadastral users who work with natural boundaries to maintain accurate parcel areas without manual correction or loss of calculated area information.

Re: Calculated Area Should Account for LineString Boundaries - Status changed to: Needs Clarification

AmirBar-Maor — Mon, 10 Nov 2025 08:54:20 GMT

@MizukiKayano2

The Calculated Area field is designed to calculate the area from the COGO measurements, if they all exist. The COGO measurements are usually in 'ground' units and reflect the real ground area. For quality assurance purposes, this area can be compared with:

Shape Area - which is calculated from the feature geometry in the spatial reference (grid) using the spatial reference units.
Stated Area - which is the legal area of the parcel, as stated on the legal document, and using the legal area units.

Questions:

How would the system identify a 'natural boundary' from a line that was cracked and has additional vertices?
When calculating an area for a natural boundary, should we internally inverse the COGO values for each small line segment? Wouldn't that mix valid 'ground' COGO with an invalid 'grid' COGO?
Why is this needed? Do the legal documents not contain the legal area that should be populated in the 'Stated Area' field?
Should we consider extending the schema to classify lines as 'natural boundaries', 'Road Frontage', ...?

Re: Calculated Area Should Account for LineString Boundaries

MizukiKayano2 — Sat, 22 Nov 2025 01:06:29 GMT

@AmirBar-Maor

1 & 4. The CPDM schema already supports line-type classification through CPDM_LineType, so the ability to identify natural boundaries (and other types such as road frontage) is effectively already present in the data model. I understand that this is not part of the base Parcel Fabric schema.

2. Inversing COGO for each small segment of a LineString could generate a more accurate area, but you raise a valid concern: doing so would mix true “ground” COGO values with derived “grid” COGO values, which undermines the integrity of the calculation.

3. What we ultimately need is a way to retrieve the original area that was calculated when the parcel was first created. At the moment, if a parcel includes a LineString, there is no mechanism to view or preserve that initial area.

The legal document does not always provide a Stated Area.
The Shape Area may change over time—for example, after a least squares adjustment, or when a neighbouring parcel modifies a shared boundary in a way that alters the geometry and therefore the area.

I look forward to your insights and to any proposed solutions on this issue.

Thank you!

Re: Calculated Area Should Account for LineString Boundaries

AmirBar-Maor — Mon, 24 Nov 2025 09:04:03 GMT

@MizukiKayano2

What is a 'Natural Boundary?

Since the 'CPDM_LineType' is specific to your information model, we could:

Try to guess which lines are a natural boundary: every line that has COGO value and a 'bend'. Would this work for LTSA?
Another option is to add a field: for example, 'IsNaturalBoundary' or 'BoundaryType' that could be set by every organization. That way we can apply the special logic only to 'natural boundaries.

Area Calculation

Since COGO values are assumed in 'Ground', and inversing the natural boundaries will be in 'Grid', we could rely on the 'Scale' field to reduce the dimensions to theoretical 'ground'. Would this work?

'Original Area' concern

What would prevent the area from being calculated again, after you run LSA, if you were to fix a data issue and build that extent again?

Re: Calculated Area Should Account for LineString Boundaries

MizukiKayano2 — Wed, 03 Dec 2025 00:06:55 GMT

@AmirBar-Maor

What is a ‘Natural Boundary’?

I would prefer option 1, as long as the system can differentiate between a multi-vertex line that is a true LineString (representing a natural boundary) versus a line that is multi-vertex only because it has been cracked by topology.

If that distinction isn’t possible, then option 2 would work.

Area Calculation

Yes, that would work. We store Rotation and Scale on both the Lines and the Record. (We also use the GroundToGridFromActiveRecord add-in and attribute rule to keep them in sync.)

‘Original Area’ Concern

How does LSA handle LineStrings?
Does it retain the LineString’s actual geometry, or does it stretch/adjust it to fit surrounding lines?

Re: Calculated Area Should Account for LineString Boundaries

AmirBar-Maor — Wed, 03 Dec 2025 07:39:56 GMT

@MizukiKayano2

Guessing natural boundaries can be problematic for many customers who have data quality issues: polylines that have many vertices. For example, curves that got rubbersheeted over the years, or cadastral agencies that use polylines instead of 2 point lines.

'Original Area'

LSA strectches the natural boundaries to the new point location as you can see here.

Before:

After applying LSA (red is the original location):

That means that if you run LSA and then use Build Extent, the calculated area will change from the "original" area.

Re: Calculated Area Should Account for LineString Boundaries

SarahSibbett — Mon, 08 Dec 2025 16:13:39 GMT

@AmirBar-Maor

When Mizuki said this in an earlier comment "What we ultimately need is a way to retrieve the original area that was calculated when the parcel was first created" I think it caused a bit of confusion.

If the Calculated Area field could be calculated successfully when the parcel was originally created, we could push that value into the Stated Area field, which would not change as a result of an LSA or an alignment.

So, your question, "What would prevent the area from being calculated again, after you run LSA, if you were to fix a data issue and build that extent again?", would not really need to be a factor. We can have a validation rule that identifies parcels where StatedArea and CalculatedArea or ShapeArea are drastically different, so I am not not concerned about that.

I don't want for confusion around this 'original area' conversation to detract from the purpose of this post, which is for Pro to be able to do a CalculatedArea calculation that takes natural boundaries into effect and does not simply use the crow flies distance.

I think your idea to inverse the COGO values for each small line segment and rely on the 'Scale' field to reduce the dimensions to theoretical 'ground' would result in exactly what this post is asking for. @MizukiKayano2 would you agree?

Re: Calculated Area Should Account for LineString Boundaries

MizukiKayano2 — Tue, 09 Dec 2025 20:52:18 GMT

@SarahSibbett @AmirBar-Maor

Yes, that's exactly what I would like; for Pro to be able to do a CalculatedArea calculation that takes natural boundaries into effect and does not simply use the crow flies distance. Thanks!

Re: Calculated Area Should Account for LineString Boundaries

AmirBar-Maor — Wed, 10 Dec 2025 10:01:13 GMT

Thanks for the clarification @MizukiKayano2 @SarahSibbett

The only sticky point is how to identify a 'Natural Boundary'.

While guessing it on your data might work, it might fail for other datasets and create many false positives.

We might need to add an optional field to account for boundary type. Such a field can be used for other use cases: symbology, labeling, zoning and planning, dedicated tools to update natural boundaries, special behavior (for example - after LSA), ...

The new Traverse SDK (3.7) might be useful for the short term