# An Efficient GNSS Coordinate Recognition Algorithm for Epidemic Management
## 6 Simulation Result
### Discussion  
For a given targeted area, the performance of O_PtInPy, L_Rect, c_, and sqr in identifying inner points was compared. For City 1, O_PtInPy generated 12.47 times the candidate points with respect to the inner points, and L_Rect generated 1.55 times the candidate points with respect to the inner points. The values for c_ and sqr in City 1 ranged from 2.02 to 1.22 and from 1.38 to 1.01. For c_ and sqr, different subarea plans generated different results. In addition to database access, the amount of calculation was also one of the metrics used to evaluate these methods. The number of confirmed points generated by applying a method affected the computation required. For O_PtInPy, the confirmed points contained all targets. Therefore, the amount of calculation needed for O_PtInPy was very large. For L_PtInPy, the targets within the range of the rectangle were confirmed points. Compared with O_PtInPy, the amount of calculation needed by L_PtInPy was reduced, but it was also very large. Taking City 1 as an example, O_PtInPy generated 1,112,188 confirmed points, and L_PtInPy generated 138,678 confirmed points, which was about 12.45% of the number of confirmed points for O_PtInPy. Then, the c_ and sqr methods were individually compared. For the subareas, sqr reduced the number by 60% to 20% with respect to c_. This shows that sqr is better than c_ in the allocation of subareas. For the outer points, sqr reduced the number by 96.9% to 25.6% with respect to c_. When the area of the subareas was smaller, the number of confirmed points would be closer to the number of inner points, and the ratio of candidate points to inner points would be closer to 1. For example, when the radius was 1/256, the ratio of sqr was about 1.01, and the ratio of c_ was between 1.23 and 1.22. When the area of the subareas was smaller, the value of sqr would be closer to 1, but the value of c_ could only stay at about 1.20. The reason is that the subareas of c_ overlapped with each other. The points within the overlapped area were repeatedly retrieved from the database. The subareas of c_ were in a circular area. However, within this circular area, only a regular hexagonal area would not overlap with other subareas, and the overlap area was about 17.3%. So, even with very efficient database systems that can support the retrieval of data within smaller partitions, c_ has limitations that sqr does not. In c_, different seed points also affected its performance, but in sqr, there was no such shortcoming. In addition, the range of the subareas was also a problem. An improper range may cause c_ to generate more candidate points than L_Rect. Accordingly, the method could determine a reasonable length (\(sl\)) for the side of a square. Algorithm 7 is a SqrSide algorithm, the inputs of which are a polygon \(P\), a point set \(P\), and a number \(n\)db. This algorithm first calculates a rectangle R with a range that can cover polygon \(P\) through RectOffPy. Next, it calculates the area of this rectangle \(R\). Then, it calculates the number \(ta\) of inner points of rectangle \(R\) through an SQL statement. \(t_{1}\) and \(t_{2}\) are continuously calculated, where \(t_{1}\) is the expected number of squares and \(t_{2}\) is the expected area of a square. Finally, the algorithm calculates the length (\(sl\)) of a square's side by using the power function pow(), i.e., \(sl^{2}=t_{2}\). Notably, in line 4, the select statement is similar to the MySQL statement for obtaining the number of records that meet the query conditions.