TBC Macros and Extensions

 View Only

 Custom Macro to Find the Center of Arc/Linestrings

Jump to  Best Answer
Richard Rehfeldt's profile image
Richard Rehfeldt posted 04-27-2026 15:05

I’m working on a TBC macro that determines the center of a manhole, which is typically represented by a combination of circles and/or line strings. We use this computed center point to generate linework from the manhole center.

The macro works correctly when the geometry is a CAD polyline. However, when the manhole is represented as a multi‑segment line string in TBC, the calculated center (or centroid) is frequently offset from the true geometric center of the arcs. The discrepancy can range anywhere from about 0.005 ft up to 0.5 ft.

It appears that the centroid or anchor point being calculated for multi‑segment line strings does not always correspond to the true center of the arc geometry.

Has anyone encountered this issue before or have insight into what I might be missing when working with multi‑segment line strings versus CAD polylines? Any advice or guidance would be greatly appreciated.

Thanks in advance!



Richard Rehfeldt

Emery Sapp & Sons, Inc.

Attachments  View in library
ESS_MHCenterForumDiag (xaml).txt 2 KB
ESS_MHCenterForumDiag (python).txt 68 KB
Richard Rehfeldt's profile image
Richard Rehfeldt posted 04-28-2026 08:26  Best Answer

Solution Summary: Finding True Center of Multi-Segment MH Linestrings in TBC

The issue was that multi-segment MH symbols (linestrings) were not storing a true “center” directly, and all common methods (centroid, bbox, best-fit circle, etc.) produced small but unacceptable offsets (0.005’–0.05’).

After deeper inspection, the key discovery was:

The true center is stored internally in the PolySeg arc nodes as RadiusPoint.

What worked

Instead of trying to compute the center from vertices, I did this:

  1. Called:
    polyseg = linestring.ComputePolySeg()
  2. Iterated through:
    polyseg.Nodes
  3. Identified arc nodes:
    Trimble.Vce.Geometry.PolySeg.Node.Arc
  4. Extracted:
    node.RadiusPoint

Why this works

  • Linestring MH symbols are stored as arc segments, not true circles
  • Each arc node contains:
    • Point / EndPoint → perimeter points ❌
    • RadiusPoint → center of the arc (true MH center) ✅

So instead of approximating the center, it is now reading it directly from TBC’s geometry engine.

Result

  • Exact center location (no offset)
  • Works for:
    • exploded multi-seg linestrings
    • joined linestrings
  • Eliminates need for centroid / best-fit / fallback logic

Key takeaway

If your geometry is built from arcs, don’t infer the center—extract it from the arc definition (RadiusPoint).

Ronny Schneider's profile image
Ronny Schneider posted 04-27-2026 18:00

I don't even try to understand the 100 pages of AI gibberish.

Have you tried something like this.

            polyseg = boundary.ComputePolySeg() # 'boundary' can be a normal Linestring or 2D polyline
            try:
                polyseg = polyseg.ToWorld()
            except:
                pass

            loopsfound = clr.StrongBox[bool]()
            centroid = clr.StrongBox[Point3D]()
            polyside = clr.StrongBox[Side]()
            region = clr.StrongBox[RegionBuilder]()

            polyseg.AreaWithLoops(loopsfound, centroid, polyside, region)

            cgrav = centroid.Value

If the center of gravity from a segmented linestring doesn't fit the "original" arc it might just be that the chording approximation was computed too coarse. If you have both, original arc and chorded linestring, check the deviation between them.