Bus AVL pings, bike-share dock occupancy, and parking sensors will feed one civic mobility application. What source pattern best describes this design?
Select an answer to reveal the explanation.
Short Explanation
Buses, bikes, and parking spots all phone home on their own. Stitch those M2M streams and you get a mobility app that sees the whole trip puzzle. Surveys and chat logs are not what the docks are broadcasting.
Full Explanation
Civic mobility applications commonly fuse multiple machine-to-machine telemetry classes—vehicle AVL, bike-share dock occupancy, and parking sensors—into one analytical product. The pattern is multi-modal M2M sourcing. Integration and time alignment across modes are the practical source challenges for resident-facing mobility apps.
Replacing all sensors with a single human survey before any app is allowed fails by concept: surveys do not replace multi-modal M2M telemetry. Claiming only relational ledger books can participate fails by concept: sensors are core Big Data sources. Using person-to-person chat logs as the sole input for dock and parking status fails by concept: chat is the wrong class for occupancy telemetry.
Exam caveat: Multi-modal M2M sources power mobility apps—do not replace sensors with surveys alone, ban sensors, or substitute chat logs for dock/parking status.
Operational check: Ingest AVL, docks, and parking on aligned clocks, document each as M2M, and verify the mobility app shows coherent multi-modal status before public launch. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.