Understanding Impacts of Security Check on Passenger Flow in a Metro Station and Improving Measures: A Case Study in Guangzhou, China
Bibliographic record
Abstract
In order to ensure the safety of passengers using metro stations and staff working at them, some cities choose to set security checks at the entrances of metro stations. There is no doubt that security check can help keep dangerous objects out of a metro station. However, the security check can also slow down the entering speed of passenger flow and lead to congestions that may affect passengers’ travel plans. How security check will impact the passenger flow and how to reduce the impact are questions that need to be addressed. In this study, metro station models were constructed using the building structure and passenger flow data of a realistic metro station in Guangzhou, China. By using the AnyLogic simulation software, the traffic characteristics of passenger flow under the scenarios with and without a security check were compared and discussed. The congested areas in the station hall and possible causes were analyzed. In addition, possible improving measures such as adding security check machines and ticket vending machines were also modeled to test their effectiveness on reducing the congestion in the station. Results show that when security checks are set at each entrance of the station being studied, the flow rate of passengers entering the gate machine could be decreased by 49.4%~83.3%, which can cause serious congestion at the entrance during rush hours. By adding security check machines and ticket vending machines at the entrances with high passenger traffic demands, the congestion near these entrances could be greatly reduced.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.001 | 0.001 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".