# Using Deep Learning for Collecting Data about Museum Visitor Behavior
## 4 Experimental Results
### Database with Collected Data  
In order to make the analysis of data collection easy and at the same time effective, we propose the following database implementation and give some sample queries that could cover the most basic and useful needs when a museum staff member wants to extract useful information about visitor behavior from the database. The data collected through the proposed system can be stored in a data structure that supports spatial and temporal analyses of visitor behavior, such as those seen in Section 4.2. Let us suppose, for example, that we have \(m\) cameras and \(n\) badges. Each camera detects, at a generic timestamp, a badge at certain coordinates from the camera. We can store all those detections in a database composed of two tables. The first table, called _position_, has attributes (TIMESTMP, CAMERA_ID, BADGE_ID, X, Y, Z) and the second table, called _camera_, has attributes (CAMERA_ID, CT, X, Y, Z). A single tuple \((t,c\_id,b\_id,x,y,z)\) of _position_ represents a detection at timestamp \(t\) from the camera \(c\_id\) of the badge \(b\_id\) at coordinates \(x,y,z\) with respect to camera \(c\_id\). A single tuple \((c\_id,ct,x,y,z)\) of _camera_ represents the coordinates \(x,y,z\) of the camera \(c\_id\) in relation to the museum. The value \(ct\) is the time period of a frame. If \(f\) is the frame rate of the camera, then we have \(ct=1/f\). For the sake of simplicity, hereafter, we suppose that \(ct\) assumes the same value for all cameras (i.e., 1/24 s), but all the discussion can be extended with simple and minimal modifications to the general case, in which cameras can have different frame rates. We note that, whilst the table _position_ is fed by the detections of the model, the table _camera_ is determined and created in advance by the system supervisor. For instance, it can be convenient to create the view _dist_positions_ using the SQL Listing A1, shown in Appendix A.  
In order to build the track of a visitor wearing the badge \(b\_id\) in the time lapses between timestamp \(t_{0}\) and timestamp \(t_{1}\), that is, the ordered timestamp sequence of the visitor positions, we may execute the SQL Listing A2.  
We also add to the database another table called _grid_ with attributes (GRID_ID, X, Y, Z), in which for each tuple \((g\_id,x,y,z)\), \(x\) and \(y\) represent the coordinates of the lower-left corner of a square inside the museum and \(z\) is the height of the floor (with respect to the museum) to which the square is referred. The width \(w\) of each square of the grid can be set, for example, to 0.5 m. Furthermore, we suppose that the badge is located somewhere between the ground floor, whose height is the coordinate \(z\) of the square and \(z=2.7\) m. In order to build a heatmap, that is, a visual indication that shows where the visitors spend more or less of the time in a given grid square inside the museum, we associate with each square element \(g\) of the grid a value that represents the sum of the number of seconds any visitor was present inside the square \(g\) in the time between \(t_{0}\) and \(t_{1}\). Listing A3 returns  
Figure 11: 3D scatterplot of four visitors.  
such values for all elements of the grid. Moreover, through Listing A4 we can detect how much time a person, identified by the badge \(b\_id\), stationed or passed in front of an artwork of the museum. We assume that the constants AX, AY, AW, and AH are given as parameters of the query and they represent what we consider as the space in front of the artwork and AZ the height of the floor (with respect to the museum) of this rectangle.