Transit planners need a reusable query that returns stops within a given radius of a depot for planning sessions. Which programmability object should they create?
Select an answer to reveal the explanation.
Short Explanation
A table-valued function is the transit planner’s reusable “stops near this depot” result set—you pass the depot and radius, you get rows back, not a single mashed-together string. That is the civic tool for spatial/route planning lists.
Full Explanation
Transit planning sessions need a reusable parameterized query that returns multiple stop rows near a depot, not a single concatenated string. A table-valued function (TVF) returns a rowset for a given depot and radius, so planners can SELECT, join, or filter the stops as relational data inside Azure SQL. That programmability object matches “return the set of stops” requirements for civic route planning. A scalar function that concatenates stop names collapses the set into one string, forcing parsers to re-split what should remain rows. A DEFAULT that inserts a hard-coded downtown stop on every plan row neither parameterizes radius nor returns a filtered set. A ledger table of depots protects integrity of depot rows; it does not produce parameterized stop result sets. Caveat: prefer inline TVFs when possible for better optimization versus multi-statement TVFs; ensure spatial or distance predicates are supported by appropriate indexes so radius filters remain efficient as the stop network grows. Operational check: execute the TVF for a depot with a known nearby stop set and a tight radius, confirm the expected stops return as rows with stable columns, then widen the radius and verify additional stops appear without changing the function definition.