Advice from the poster session after our midterm presentations helped us to narrow in on a definable and presentable goal: coverage optimization.
In dealing with WiFi data that can indicate high-level movement patterns, it becomes easy to think that the most, if not only, useful application of the data set is working with mobility. For some time, we assumed that we needed to ‘solve’ mobility, figure out what indicated migrations from one location to another, and extrapolate meaningful inferences about events from these trends. Thinking about crowd distribution was in the back of our heads, but was almost discarded as being too obvious, too simple to calculate.
Considering some specific use cases of our deliverable, it becomes clear that crowd distributions may be even more informative than calibrated mobility metrics. At Georgia Tech, having a general idea of the builds that people will be in past midnight is very useful for crime prevention. At airports, on the other hand, crowd stampeding is a legitimate hazard that law and safety officials are trying to mitigate. If we can model congestion, we can not only improve associated policies but provide real-time information on dangerous high-level behaviors. This information is deliverable to both safety officials, and to the crowds themselves: if an area is becoming a potential hazard, why not notify the coagulating people, whether by automated announcements or SMS?
Mobility continues to play a role, but instead of assessing sequential route behaviors, we can focus on route usage. This problem is more tractable – instead of attempting to calculate where crowds are intending to go, we simply need to determine which routes are getting the most use.
Aside from thinking about coverage, it has been a primary concern to determine what data will look like when refined and given to our interface. Particularly, it is not enough to give coverage information for every hour of every day. For the tool to be robust and extensible to a wider variety of use cases, the high-level data design is as important as the interface design.
The current approach to ensuring this generalizability is responding to user-defined queries with the same data structure. Consider this as the following analogy: you want to know everything about a couple cakes that I am baking (query) – instead of listing off the properties of each cake, I give you a card that represents each cake in a consistent format (response). These cards are the data structures that the user asks for, and because they are presented in a consistent format, the interface can represents them in an intuitive and comparative fashion.
Applied to our scenario, these cards represent usage and mobility information:
- If the user asks to know what is happening across all of time, the interface gives one card that represents an ‘average’ day over time.
- If the user asks to know what is happening just on July 4th, the interface gives two cards: one that represents an ‘average’ day over time (but not July 4th), and another that represents only July 4th. Now the cards can be compared side-by-side.
- If the user asks to know what is happening during football games, the interface again gives two cards: one that represents an ‘average’ day over time (but not the football games), and another the represents all of the football games. Similarly, you could choose to have one card for each football game, if there are not many.
- In the current interface prototype, the user can filter down to observing specific locations as well. The user might ask to know: specifically at the Student Commons building, what are the high-level crowd behaviors that happen all of time? From this point, the interface can simply cluster all days at the Student Commons by the associated usage and mobility data, and present a card for each cluster.
From this clearly defined methodology, developing the front-end pipeline even without pristine data becomes possible. Although our interface appears the same as we have presented in the past, it is now armed with time and place querying tools, and a system for measuring, formatting, and rendering incoming data. The following display represents a single blue card, which contains dummy data:
