## 3 Related Work  
Trajectory similarity search is a foundational operation for many spatiotemporal analysis applications. It can be used for a real-time recommendation system [2; 8; 9] and urban planning scenarios [3; 10]. Many works [10; 11; 12; 13; 14; 15; 16; 17; 18; 19; 20; 21; 22; 23; 24] are devoted to further exploration of the similarity of the trajectory. Many works have been done on trajectory similarity search for different purposes [12; 13; 14; 16; 17; 18; 19; 20; 21; 22; 23; 24]. Generally, these works adopt a two-stage search solution. Before these two stages, it abstracts spatiotemporal features from the trajectory dataset and builds an index for all trajectories. In the filtering stage, unnecessary computations are pruned via this index. In detail, based on this index and a predefined similarity measure function, the upper and lower bounds of similarity between the input trajectory and the candidate trajectory can be inferred. In the refinement stage, these candidate trajectoriesare validated by the similarity measure function and a threshold. A candidate will be saved in the final result if its similarity score is larger than the threshold. Further, these index-based methods can be classified into three categories: spatial partition tree [20; 21], spatiotemporal grid [15; 20], and distributed index, respectively [18; 19]. The first category firstly builds a partition tree by the MBR (minimum bounding rectangle) of the trajectory dataset, whose MBR does not intersect with the MBR of the target trajectory and can be pruned. The second category firstly divides the time and space dimensions into a set of uniform grids and assigns each grid with a unique geographical code. For a given target trajectory, it can quickly identify a grid that has an intersection of the region produced by the target trajectory. The third often builds a two-layer distributed index, the global index and the local index. The search algorithm adopts the global and local index to accelerate the filtering and refining stages. In order to handle a large volume of trajectory datasets, a set of studies resort to big data technology to conduct trajectory similarity searches. For example, a group of studies is implemented on Map Reduce [16; 24], while a group of studies is implemented on Spark [12; 16; 19; 21]. Other parallelized trajectory similarity search algorithms are implemented on CPU [15; 18; 23] or GPU clusters [22]. However, most studies of them take GPS trajectory as the research object, and few works have been proposed to discuss trajectory similarity search in metro scenarios. In addition, their corresponding optimal strategies of aforementioned solutions are designed for GPS trajectory, it is hard to apply such kind of solution on trajectory similarity search in the metro scenario. The reason is that metro trajectories have significantly different spatiotemporal characteristics from GPS trajectories. For example, the sampling rate and positioning accuracy, details already discussed in Section 2.1. GLTC [7] has studied trajectory similarity join and data fusion in the metro transportation system. The differences between PMMTss and GLTC are two fold. Firstly, the problems they addressed are different. PMMTss is to resolve trajectory similarity search while GLTC is to address trajectory similarity join. The former is a kind of lightweight query on one trajectory dataset, which takes a query trajectory and a threshold as inputs, and outputs a set of similar trajectories. The latter is a compute-intensive task, which conducts pair-wise trajectory similarity calculation across different trajectory datasets. Secondly, the similarity measure functions are different. The trajectory similarity function of PMMTss is to measure the same type of trajectories produced by smart cards, which is derived from Jaccard and LCSS. It is an explicit method, which means that the more times they appear in the same station at the same time, the more similar they are.