Route 30 + Group B catalog asymmetry — operator investigation needed

[ciotlosm]

Routes with asymmetric catalog patterns — operator action required

We can't auto-fix these via pattern traversal. The catalog (Tranzy/Transitous) describes one set of trajectories, the operator's CSV describes another, and they don't share endpoints. Filing this as a tracking issue so the operator (or Tranzy) can resolve.

Routes affected (verified against live feed, 2026-06-30)

Tier 5 no-match (catalog ↔ CSV don't agree on terminals)

Route	CSV in_stop_name	CSV out_stop_name	Catalog dir 0 first	Catalog dir 1 first	Pattern asymmetry
30	Disp. Grigorescu	Disp. IRA	Radio România Cluj	EXPO Transilvania	4 distinct terminal names — dir 0 ends at Disp. IRA, dir 1 ends at Disp. Grigorescu. Neither pattern contains the other's start.
M26	Cluj-Napoca	M-Floresti Cetate Pl.	M-Florești Cetate Plecare	(no pattern)	CSV in_stop_name is a city name, not a stop.
29S	Sf.Ioan	Pod Traian	Roata Faget Plecare	P-ța M. Viteazul Sud	CSV col 0 (Sf.Ioan) doesn't appear in any pattern. CSV col 1 (Pod Traian) is mid-dir-1.

Tier 5 partial-swap (one CSV column matches opposite direction, other doesn't)

Route	CSV col 0	CSV col 1	Catalog dir 0 first	Catalog dir 1 first	Diagnosis
46	Opera	Giratie Drum Faget	Girație Drum Făget	Teatru	col 1 matches dir 0 (fuzzy); col 0 (Opera) not in any pattern.
20	Opera	Biserica Borhanci Est	Biserica Borhanci Est	Posada	col 1 matches dir 0 (exact); col 0 (Opera) not in any pattern.

What's been done

• Pattern traversal implemented in PR n3ary/cluj-napoca-gtfs-adapter#4 (findLabelInPattern helper)
• For Group A (M24, 47, 57L), traversal silently resolves the tier (better match found mid-pattern)
• For Group B (the 5 routes above), traversal finds partial matches but they don't give a consistent direction — code emits WARN and uses catalog direction_id

What's needed

For each route:

1. Operator/City Hall inquiry: did the line's actual physical route change? If yes, the catalog needs updating (and Tranzy RT feed).
2. CSV data quality: for M26, the in_stop_name = "Cluj-Napoca" looks like a placeholder (city name), not a stop. Is this a CSV publisher issue?
3. Tranzy catalog sync: for routes 30/46/20, the catalog appears stale relative to the operator's current published schedule.

Until the operator responds or Tranzy updates, the published GTFS keeps:

• Catalog direction_id (preserves reconciler compatibility with RT feed)
• Catalog route_long_name (operator's CSV trajectory doesn't exist in catalog)
• WARN in build log with categorized sub-type (catalog-out-of-date / csv-placeholder / no-match-asymmetric)