Umbrella: Reports feature (feature-requests #217).
Reported behavior: a user with a small switching layout (7 physical switches, by
their own count) saw the Unconnected Endpoints, Turnout Density, and Track
Lengths reports all agree on a turnout-type count of 13 instead of 7.
Root cause investigated this session, confirmed in source (not the reporter's
file yet -- still requested): XTrkCAD's native TURNOUT track record covers
turnouts AND crossings AND single/double slip switches -- turnout.c's drawing
code explicitly handles "Crossing, single- and double-slip" through the same
T_TURNOUT type. Every report that tallies "turnouts" (Turnout Density Report,
Track Lengths Report) counts every T_TURNOUT-type object via
GetTrkType(trk) == T_TURNOUT, with no distinction between an actual switch
(has moving points) and a crossing (no moving points at all, just a fixed
intersection). Confirmed the MCP Python reference implementation
(mcp/src/xtrkcad_mcp/server.py) does the same thing via t.kind == "TURNOUT",
so this is consistent by-design behavior across both implementations, not a
divergence bug. Verified against the in-tree example app/lib/examples/
port_dinllean.xtc: 133 plain turnouts + 22 crossings/double-slips = 155 raw
TURNOUT records, and the Turnout Density Report correctly (per its own current
design) reports "Total turnouts: 155".
Documentation fixed this session (reportsm.dox, Turnout Density Report and
Track Lengths Report pages) to explicitly note that the turnout count includes
crossings and slip switches.
Filing as a follow-on enhancement idea: should these reports distinguish
actual switches (turnouts with selectable Normal/Reverse paths) from crossings
(fixed, no alternate path) and slip switches (multiple selectable paths)? The
underlying turnout data has no explicit "kind" flag for this -- the file
format's TURNOUT record doesn't carry a switch/crossing/slip classification,
only a free-text manufacturer description (locale-dependent, not reliable to
match against) and a PATH list whose entry count differs by sub-type (an
ordinary turnout typically has 2 paths -- Normal/Reverse; a plain crossing
typically has a single through path with no selection; slips have more).
A path-count-based heuristic looks feasible but needs verification against
real .xtp definitions before committing to it, and the same distinction would
need porting to the MCP reference to keep both implementations in sync.
Not started -- filed as an investigation/backlog item per the Reports feature's
post-release configurability queue, not blocking the current doc fix.
Anonymous
Doc fix posted: PR #194 (github.com/adbyrne/XTrkCAD/pull/194) clarifies reportsm.dox's Turnout Density Report and Track Lengths Report pages to explicitly note the turnout count includes crossings and slip switches, not just ordinary turnouts. Report behavior itself is unchanged -- this is a documentation fix only. The follow-on idea of distinguishing switches from crossings/slips in the reports themselves stays open on this ticket as a separate, unscoped enhancement.
Correction: this ticket's status was briefly (and incorrectly) set to "fixed" -- only the documentation clarification is done (PR #194, merged to Hg mainline GTK3V2MAIN r7260/SF, pushed). The follow-on enhancement idea (distinguishing switches from crossings/slips in the reports themselves) is still open and unscoped. Reverting status to open to reflect that accurately.