A rideshare data-sharing agreement will push external trip aggregates to the city every night through a partner interface. How should the analytics team classify this feed?
Select an answer to reveal the explanation.
Short Explanation
Nightly partner dumps are still Big Data sources — they just live outside city hall’s servers. Treat the rideshare feed as an external API contribution, not a paper-ticket museum piece. It adds coverage; it does not replace every city sensor with video frames.
Full Explanation
Partner and third-party APIs are legitimate Big Data sources for civic programs. A rideshare agreement pushing nightly trip aggregates through a partner interface extends municipal mobility views when contracts, schemas, and refresh windows are governed. Classification as an external API source keeps architecture and privacy reviews aligned with how the data actually arrives.
Treating the feed as proof that only on-premise paper tickets count fails by concept: external digital aggregates are valid sources. Disabling all municipal AVL because partner data replaces city sensors fails by concept: partner feeds complement, not erase, city sensors. Treating the feed as a streaming video archive of raw camera frames fails by concept: trip aggregates are not raw video.
Exam caveat: Classify partner trip aggregates as external API sources—complementary to city sensors, not paper-only dogma, AVL deletion, or video archives.
Operational check: Contract schema and nightly refresh, inventory the feed as external API, retain city AVL for authoritative vehicle location, and review privacy fields before analytics publish. Document residual risk for civic operators and revisit after the next production change window.