Cycling Trajectory-Based Navigation Independent of Road Network Data Support

: The popularization of smart phones and the large-scale application of location-based services (e.g., exercises, traveling and food delivery via cycling) have resulted in the emergence of massive amounts of personalized cycling trajectory data, spurring the demand for map navigation based on cycling trajectories. Therefore, in the current paper, we propose a cycling trajectory-based navigation algorithm without the need for road network data support. The proposed algorithm focuses on extracting navigation information from a given trajectory and then guiding others to the destination along the original trajectory. In particular, the algorithm analyzes the coordinate and azimuth angle data collected by the built-in positioning and direction sensors of mobile smart phones to identify several turning modes from the provider’s cycling trajectory. In addition, the interference of the trafﬁc conditions during data collection is considered in order to improve the recognition accuracy of the turning modes. The turning modes in the trajectory are subsequently transformed into navigation information and shared with users, so as to realize the shared navigation of the cycling trajectory. Experimental results indicate that the algorithm can accurately extract the turning feature points from cycling trajectory data, recognize various turning modes and generate correct navigation messages, thereby guiding users to arrive at the destination safely and accurately along the original trajectory. The algorithm is independent of electronic map platforms and does not require road network data support.


Introduction
The growing popularity of social networks has enhanced the demand for trajectorybased navigation, that is, sharing individual's trajectory data with others, and navigating other trajectories based on the trajectory data themselves. Thus, in this paper, we propose a cycling trajectory-based route navigation algorithm that is independent of road network data support. The purpose of the algorithm is to identify the turning modes from a given cycling trajectory, convert the turning modes into navigation information, and share all this with other users.
As the core function of electronic maps, map navigation is closely related to the daily travel of map users. Traditional map navigation methods are typically reduced to the shortest path-finding problem, and their representative methods can be divided into two categories: label setting (e.g., the Dijkstra algorithm [1]) and label correction (e.g., the Bellman-Ford algorithm [2]). In order to speed up the calculation efficiency of the shortest path planning algorithm in large-scale networks, the authors of [3] propose the famous A* algorithm, with the aim of improving the search efficiency of the shortest path through heuristic searching. Based on multi-level and hierarchical characteristics of road networks, scholars have also proposed a series of the shortest path accelerated search methods based on multi-level road networks [4][5][6][7][8][9]. In addition to employing distance as Definition 6. (Navigation Message): Navigation message is the guidance information for cyclists at important turns, including turn left ahead, turn right ahead, turn around ahead, etc.
The proposed algorithm makes an important assumption: the cycling trajectory collected and shared by individual providers should completely comply with traffic rules, and thus there should be no traffic violations, such as retrograde, etc. Cycling trajectory-based navigation requires the extraction and sharing of important traffic information from a given cycling trajectory, such as going straight, left turn, right turn, turn around, etc. (Figure 1). Although the proposed algorithm does not require the support of road network data, the navigation route provider must carry the smart phone during cycling when collecting trajectory data. The algorithm recognizes and extracts the turning feature points based on the coordinate data collected by the positioning sensor, and subsequently combines the azimuth angle data of the direction sensor to further determine the turn modes, thus generating navigation messages to share with other users. The navigation route users are only required to collect the positioning coordinates of the trajectory via their mobile phone, not the direction data. The user is then able to reach their destination following the navigation messages. Cycling is more unpredictable than driving and is susceptible to numerous interferences. Therefore, a targeted algorithm is required. Moreover, cycling is also more flexible than driving; when the cyclist is found to deviate from the navigation route, they will be prompted to turn and can correct the route at any time. Consequently, the sharing navigation of cycling trajectories is completely feasible in practical applications.
The proposed algorithm makes an important assumption: th lected and shared by individual providers should completely co and thus there should be no traffic violations, such as retrograde based navigation requires the extraction and sharing of important a given cycling trajectory, such as going straight, left turn, righ ( Figure 1). Although the proposed algorithm does not require the data, the navigation route provider must carry the smart phone d lecting trajectory data. The algorithm recognizes and extracts th based on the coordinate data collected by the positioning sensor, bines the azimuth angle data of the direction sensor to further de thus generating navigation messages to share with other users. Th are only required to collect the positioning coordinates of the tra phone, not the direction data. The user is then able to reach their d navigation messages. Cycling is more unpredictable than drivin numerous interferences. Therefore, a targeted algorithm is requir also more flexible than driving; when the cyclist is found to dev route, they will be prompted to turn and can correct the route at the sharing navigation of cycling trajectories is completely feasi tions.

Cycling Trajectory Sharing Navigation Based on Mobile Pho
We set the sampling interval of the mobile phone positionin as 1000 ms and 30 ms, respectively. The direction sensor obtains roll angles ( Figure 2). The azimuth angle is the angle between the Y-axis and the direction of the north pole of the geomagnetic field rotates around the Z-axis; the pitch angle is the angle between the Y-axis and the horizontal direction when the phone rotates aroun angle is the angle between the positive direction of X-axis and when the phone rotates around the Y-axis. The mobile phone m acquisition, while the initial posture of the mobile phone is unres

Cycling Trajectory Sharing Navigation Based on Mobile Phone Sensors
We set the sampling interval of the mobile phone positioning and direction sensors as 1000 ms and 30 ms, respectively. The direction sensor obtains the azimuth, pitch and roll angles ( Figure 2). The azimuth angle is the angle between the positive direction of the Y-axis and the direction of the north pole of the geomagnetic field when the mobile phone rotates around the Z-axis; the pitch angle is the angle between the positive direction of the Y-axis and the horizontal direction when the phone rotates around the X-axis; and the roll angle is the angle between the positive direction of X-axis and the horizontal direction when the phone rotates around the Y-axis. The mobile phone must be fixed during data acquisition, while the initial posture of the mobile phone is unrestricted.

Preprocessing the Cycling Trajectory Data
The cycling trajectory data are processed via the following three steps: (i) remov abnormal points; (ii) removal of staying points; and (iii) extraction of turning fea points.
When there are no GPS satellite signal, the collected coordinate data may de greatly from the actual coordinates, and thus abnormal points must be removed. Du the low speed during cycling, the Euclidean distance between adjacent coordinate p will not be highly variable. If the difference in distance between the current and prev trajectory points is large, the trajectory point will be removed. Due to effects of GPS tioning errors, when the bicycle stops at a certain point, the coordinate data may drift and forth to form a point cluster, which can be removed by a compression algorithm We employ the DP (Douglas-Peucker) algorithm for the trajectory compressio extract feature points and eliminate staying points. The algorithm, which uses the ve deviation distance D as the threshold, first connects the start and end points of the tr tory data. The distance from other trajectory points to the line segment is then calcu to determine the point with the maximum distance : if < D, the interme points are removed; otherwise, the trajectory is divided into two sections based on point. The procedure is repeated recursively for the two sections until there are no tr tory points between the first and last points.

Turning Mode Recognition in Cycling Trajectory Based on Mobile Phone Sensors
The spatial characteristics of the turning can be directly observed by visualizin coordinate data collected via the positioning sensor. In general, as turning is perfor the angle between the adjacent trajectory segments will gradually transition from fla cling in a straight line) to obtuse (during turning). When turning ends, the angle beco flat (cycling in a straight line) again. Based on this process, the turning sequence ca obtained. However, the coordinate data collected by the positioning sensor are not pletely correct, as abnormal points may appear due to, for example, entering a tu without a satellite signal, or the obstruction of tall buildings. As a result, despite cy in a straight line, the angle between the adjacent trajectory segments may be too a Therefore, in order to enhance the robustness of the algorithm, the positioning sens used as the principal sensor and the direction sensor is taken as the auxiliary. These sensors are combined to comprehensively recognize turns. Figure 3 presents the v tions in the three-axis data of the direction sensor during a 20° left turn (Figure 3a), a 90° turn ( Figure 3b) and a 180° turn (Figure 3c). The direction sensor of the mobile p is able to accurately identify multiple turning phenomena. When the cycle turns, the p and roll angle do not change significantly, while the azimuth angle changes drastic

Preprocessing the Cycling Trajectory Data
The cycling trajectory data are processed via the following three steps: (i) removal of abnormal points; (ii) removal of staying points; and (iii) extraction of turning feature points.
When there are no GPS satellite signal, the collected coordinate data may deviate greatly from the actual coordinates, and thus abnormal points must be removed. Due to the low speed during cycling, the Euclidean distance between adjacent coordinate points will not be highly variable. If the difference in distance between the current and previous trajectory points is large, the trajectory point will be removed. Due to effects of GPS positioning errors, when the bicycle stops at a certain point, the coordinate data may drift back and forth to form a point cluster, which can be removed by a compression algorithm.
We employ the DP (Douglas-Peucker) algorithm for the trajectory compression to extract feature points and eliminate staying points. The algorithm, which uses the vertical deviation distance D as the threshold, first connects the start and end points of the trajectory data. The distance from other trajectory points to the line segment is then calculated to determine the point with the maximum distance D max : if D max < D, the intermediate points are removed; otherwise, the trajectory is divided into two sections based on this point. The procedure is repeated recursively for the two sections until there are no trajectory points between the first and last points.

Turning Mode Recognition in Cycling Trajectory Based on Mobile Phone Sensors
The spatial characteristics of the turning can be directly observed by visualizing the coordinate data collected via the positioning sensor. In general, as turning is performed, the angle between the adjacent trajectory segments will gradually transition from flat (cycling in a straight line) to obtuse (during turning). When turning ends, the angle becomes flat (cycling in a straight line) again. Based on this process, the turning sequence can be obtained. However, the coordinate data collected by the positioning sensor are not completely correct, as abnormal points may appear due to, for example, entering a tunnel without a satellite signal, or the obstruction of tall buildings. As a result, despite cycling in a straight line, the angle between the adjacent trajectory segments may be too acute. Therefore, in order to enhance the robustness of the algorithm, the positioning sensor is used as the principal sensor and the direction sensor is taken as the auxiliary. These two sensors are combined to comprehensively recognize turns. Figure 3 presents the variations in the three-axis data of the direction sensor during a 20 • left turn (Figure 3a), a right 90 • turn ( Figure 3b) and a 180 • turn (Figure 3c). The direction sensor of the mobile phone is able to accurately identify multiple turning phenomena. When the cycle turns, the pitch and roll angle do not change significantly, while the azimuth angle changes drastically. When the cycle turns right (left), the azimuth angle gradually increases (decreases), and the angle change is equal to the amplitude of the turn. The recognition of the turning mode in a cycling trajectory based on mobile phone sensors includes two key factors: the identification of turn sequences and the determination of turning modes.  3.2.1. Discovery of the Turn Sequence Figure 4 presents the method adopted to recognize turning sequences, which is composed of a series of turning feature points. The angles (i∈1…n − 1)between vectors and , namely, the turning angles from line segment to line segment , can be described as： where point set = ， ， … ， ， (0= < = , m ≤ n) contains the turning feature points extracted by the trajectory compression algorithm. Angle threshold α and turning feature point distance threshold L are fixed. The thresholds α and L are the empirical parameters used in the program according to the inherent geometric characteristics of road features. The threshold α is used to distinguish a straight segment from a curved segment. The threshold L is used to merge two turns that are close together and to determine whether the current turn has been completed or not. If the turning angle at a turning feature point is greater than threshold , the point is added to the turning sequence. If point is on the left-hand side of vector , the turning type at point is a left turn, otherwise it is a right turn. Furthermore, if the next feature point simultaneously satisfies the following three conditions, it will continue to be added to the turning sequence: (i) the turning angle of the feature point is greater than the turning angle threshold ; (ii) the turning type of the feature point is equal to that of the previous feature point; and (iii) the distance between the current and previous feature points is less than distance threshold L. If the feature points do not satisfy the above conditions, the recognition of the turn sequence will stop and the recognition of the next turn sequence will continue. Figure 4 demonstrates three turn sequences, < >, < > and < , >.   Figure 4 presents the method adopted to recognize turning sequences, which is composed of a series of turning feature points. The angles θ i (i∈1 . . . n − 1) between vectors P i−1 P i and P i P i+1 , namely, the turning angles from line segment P i−1 P i to line segment P i P i+1 , can be described as:

Discovery of the Turn Sequence
where point set T = P c 0 , P c 1 , . . . , P c m−1 , P c m (0 = c 0 < c m = n, m ≤ n) contains the turning feature points extracted by the trajectory compression algorithm. Angle threshold α and turning feature point distance threshold L are fixed. The thresholds α and L are the empirical parameters used in the program according to the inherent geometric characteristics of road features. The threshold α is used to distinguish a straight segment from a curved segment. The threshold L is used to merge two turns that are close together and to determine whether the current turn has been completed or not. If the turning angle at a turning feature point P i is greater than threshold α, the point is added to the turning sequence. If point P i+1 is on the left-hand side of vector P i−1 P i , the turning type at point P i is a left turn, otherwise it is a right turn. Furthermore, if the next feature point simultaneously satisfies the following three conditions, it will continue to be added to the turning sequence: (i) the turning angle of the feature point is greater than the turning angle threshold α; (ii) the turning type of the feature point is equal to that of the previous feature point; and (iii) the distance between the current and previous feature points is less than distance threshold L. If the feature points do not satisfy the above conditions, the recognition of the turn sequence will stop and the recognition of the next turn sequence will continue. Figure 4 demonstrates three turn sequences, <P 1 >, <P 2 > and <P 4 ,  Figure 4 presents the method adopted to recognize turning sequences, which is composed of a series of turning feature points. The angles (i∈1…n − 1)between vectors and , namely, the turning angles from line segment to line segment , can be described as：

Discovery of the Turn Sequence
contains the turning feature points extracted by the trajectory compression algorithm. Angle threshold α and turning feature point distance threshold L are fixed. The thresholds α and L are the empirical parameters used in the program according to the inherent geometric characteristics of road features. The threshold α is used to distinguish a straight segment from a curved segment. The threshold L is used to merge two turns that are close together and to determine whether the current turn has been completed or not. If the turning angle at a turning feature point is greater than threshold , the point is added to the turning sequence. If point is on the left-hand side of vector , the turning type at point is a left turn, otherwise it is a right turn. Furthermore, if the next feature point simultaneously satisfies the following three conditions, it will continue to be added to the turning sequence: (i) the turning angle of the feature point is greater than the turning angle threshold ; (ii) the turning type of the feature point is equal to that of the previous feature point; and (iii) the distance between the current and previous feature points is less than distance threshold L. If the feature points do not satisfy the above conditions, the recognition of the turn sequence will stop and the recognition of the next turn sequence will continue. Figure 4 demonstrates three turn sequences, < >, < > and < , >.  When cycling under tall buildings or in the shade of trees, the coordinate data collected by the positioning sensor may exhibit large errors. In particular, despite cycling in a straight line, the angle between adjacent trajectory segments may be too sharp. Therefore, the turn sequence recognition can be combined with the azimuth angle data of the direction sensor for an auxiliary evaluation. For example, in Figure 3, suppose that P 0 − P 3 was originally a straight segment. Due to the large error of the collected coordinate data, <P 1 > and <P 2 > are mistakenly identified as turning sequences. In this case, the wrong turning sequence can be eliminated by combining with azimuth angle data. Taking the turning sequence <P 1 > as an example, we can obtain azimuth angles γ A and γ B of the trajectory points in the center of line segments P 0 P 1 and P 1 P 2 , respectively. If the turning angle determined via the coordinates is equal to the difference between γ A and γ B , the turn sequence is retained; otherwise, it is deleted.

Determination of Turning Modes
The turning mode can be determined by turning amplitude, which is calculated by accumulating turning angles in the turning sequence. For example, Figure 5a presents a series of trajectory feature points during a left turn, while Figure 5b depicts the corresponding azimuth angle change via the direction sensor. If we denote the extracted turning sequence as <P 1 , P 2 , P 3 >, where points P 1 and P 3 are the starting and ending points of the turning sequence, then γ P 0 P 1 and γ P 3 P 4 are the azimuth angles corresponding to the trajectory point at the center of segment P 0 P 1 and polyline segment P 3 P 4 , respectively. We subsequently determine the following three parameters: (i) the turning angle θ between → P 0 P 1 and → P 3 P 4 (Formula (1)); (ii) turning amplitude β (the cumulative turning angles from point P 1 to P 3 (Formula (2))); and (iii) the azimuth angle difference ∆γ between γ P 0 P 1 and γ P 3 P 4 (Formula (3)): Under normal circumstances, θ, β, and ∆γ should be approximately equal, and can be used to determine the turning mode and turning amplitude. Moreover, θ and β can be calculated using the trajectory point coordinates without data from the direction sensor. However, due to the potentially large errors of the GPS coordinates under adverse conditions, the azimuth angle data need to also be integrated into the calculation process for the auxiliary judgment. Therefore, the three parameters are employed to jointly determine the turning mode by taking the median of the three values as the whole turning amplitude. When cycling under tall buildings or in the shade of trees, the coordinate data co lected by the positioning sensor may exhibit large errors. In particular, despite cycling a straight line, the angle between adjacent trajectory segments may be too sharp. Ther fore, the turn sequence recognition can be combined with the azimuth angle data of th direction sensor for an auxiliary evaluation. For example, in Figure 3, suppose that was originally a straight segment. Due to the large error of the collected coordina data, < > and < > are mistakenly identified as turning sequences. In this case, the wron turning sequence can be eliminated by combining with azimuth angle data. Taking th turning sequence < > as an example, we can obtain azimuth angles γ and γ of th trajectory points in the center of line segments and , respectively. If the turnin angle determined via the coordinates is equal to the difference between γ and γ , th turn sequence is retained; otherwise, it is deleted.

Determination of Turning Modes
The turning mode can be determined by turning amplitude, which is calculated b accumulating turning angles in the turning sequence. For example, Figure 5a presents series of trajectory feature points during a left turn, while Figure 5b depicts the corr sponding azimuth angle change via the direction sensor. If we denote the extracted tur ing sequence as < ， ， >, where points and are the starting and ending poin of the turning sequence, then and are the azimuth angles corresponding the trajectory point at the center of segment and polyline segment , respe tively. We subsequently determine the following three parameters: (i) the turning angle between ⃗ and ⃗ (Formula (1)); (ii) turning amplitude (the cumulative turnin angles from point to (Formula (2))); and (iii) the azimuth angle difference ∆ b tween and (Formula (3)): Under normal circumstances, , , and ∆ should be approximately equal, and ca be used to determine the turning mode and turning amplitude. Moreover, and ca be calculated using the trajectory point coordinates without data from the direction se sor. However, due to the potentially large errors of the GPS coordinates under adver conditions, the azimuth angle data need to also be integrated into the calculation proce for the auxiliary judgment. Therefore, the three parameters are employed to jointly dete mine the turning mode by taking the median of the three values as the whole turnin amplitude.  The turning range varies with the road intersection ( Figure 6). For Y-shaped intersections (Figure 6a), the turning range lies within 30-60 • , while for cross-shaped intersections (Figure 6b), the turning range is about 90 • . Therefore, when the turning range is between −150 • and −30 • , 30 • and 150 • , and −30 • and 30 • , the navigation message is "turn left", "turn right" and "go straight", respectively. Additional turning ranges prompt "turn around". The turning range varies with the road intersection ( Figure 6). For Y-shaped intersec tions (Figure 6a), the turning range lies within 30°− 60°, while for cross-shaped intersec tions (Figure 6b), the turning range is about 90°. Therefore, when the turning range i between −150° and −30°, 30° and 150°, and −30° and 30°, the navigation message "turn left", "turn right" and "go straight", respectively. Additional turning ranges promp "turn around".

Recognition and Navigation of Complex Turning Mode
Cyclers often face complex traffic situations such as lane changing, narrowing or wid ening road surfaces (Figure 7a), and avoiding obstacles (Figure 7b). Thus, cycling trajec tories typically exhibit many twists, resulting in small curves in the trajectory data. Th can act as a false indication of a turn. However, the angles between the adjacent trajector segments in these small curves are likely to be filtered through the trajectory compressio algorithm due to their small size. Moreover, the accumulated turning angles are also likel to be small. For example, in Figure 7a, the directions of vectors ⃗ and ⃗ are almos the same, as are those of ⃗ and ⃗ , and hence they will not be misjudged as turns. Despite the exclusion of small curves in the trajectory, complex traffic conditions ca still lead to difficult turning modes. Here, we denote a turn mode as complex if the corre sponding feature turning points with the largest turning angle in adjacent turn sequence are too close. In the following, we describe three typical examples. Figure 8a presents tw adjacent turn sequences, represented by an initial right turn followed by moving straigh

Recognition and Navigation of Complex Turning Mode
Cyclers often face complex traffic situations such as lane changing, narrowing or widening road surfaces (Figure 7a), and avoiding obstacles (Figure 7b). Thus, cycling trajectories typically exhibit many twists, resulting in small curves in the trajectory data. This can act as a false indication of a turn. However, the angles between the adjacent trajectory segments in these small curves are likely to be filtered through the trajectory compression algorithm due to their small size. Moreover, the accumulated turning angles are also likely to be small. For example, in Figure 7a, the directions of vectors − − → P 0 P 1 and − − → P 2 P 3 are almost the same, as are those of − − → P 0 P 1 and − − → P 4 P 5 , and hence they will not be misjudged as turns. The turning range varies with the road intersection ( Figure 6). For Y-shaped intersections (Figure 6a), the turning range lies within 30°− 60°, while for cross-shaped intersections (Figure 6b), the turning range is about 90°. Therefore, when the turning range is between −150° and −30°, 30° and 150°, and −30° and 30°, the navigation message is "turn left", "turn right" and "go straight", respectively. Additional turning ranges prompt "turn around".

Recognition and Navigation of Complex Turning Mode
Cyclers often face complex traffic situations such as lane changing, narrowing or widening road surfaces (Figure 7a), and avoiding obstacles (Figure 7b). Thus, cycling trajectories typically exhibit many twists, resulting in small curves in the trajectory data. This can act as a false indication of a turn. However, the angles between the adjacent trajectory segments in these small curves are likely to be filtered through the trajectory compression algorithm due to their small size. Moreover, the accumulated turning angles are also likely to be small. For example, in Figure 7a, the directions of vectors ⃗ and ⃗ are almost the same, as are those of ⃗ and ⃗ , and hence they will not be misjudged as turns. Despite the exclusion of small curves in the trajectory, complex traffic conditions can still lead to difficult turning modes. Here, we denote a turn mode as complex if the corresponding feature turning points with the largest turning angle in adjacent turn sequences are too close. In the following, we describe three typical examples. Figure 8a presents two adjacent turn sequences, represented by an initial right turn followed by moving straight Despite the exclusion of small curves in the trajectory, complex traffic conditions can still lead to difficult turning modes. Here, we denote a turn mode as complex if the corresponding feature turning points with the largest turning angle in adjacent turn sequences are too close. In the following, we describe three typical examples. Figure 8a presents two adjacent turn sequences, represented by an initial right turn followed by moving straight for a short distance, and lastly, a left turn (unlike the change of lanes in Figure 7a). This example generally occurs on a narrow road. In Figure 8b, three consecutive turn sequences are represented on a circular road: a right turn, followed by a continuous left turn, and finally, a right turn. Figure 8c also depicts three consecutive turn sequences, represented by an initial left turn, followed by a right turn and a subsequent left turn, occurring on a large road intersection. In fact, Figure 8c denotes a left turn from P 1 to P 3 at the intersection, yet the turning process obviously violates traffic rules because one segment is retrograde. This is commonly observed in daily life. For these three special turning modes, the generated navigation message is distinct from that of normal turning modes. for a short distance, and lastly, a left turn (unlike the change of lanes in Figure 7a). This example generally occurs on a narrow road. In Figure 8b, three consecutive turn sequences are represented on a circular road: a right turn, followed by a continuous left turn, and finally, a right turn. Figure 8c also depicts three consecutive turn sequences, represented by an initial left turn, followed by a right turn and a subsequent left turn, occurring on a large road intersection. In fact, Figure 8c denotes a left turn from to at the intersection, yet the turning process obviously violates traffic rules because one segment is retrograde. This is commonly observed in daily life. For these three special turning modes, the generated navigation message is distinct from that of normal turning modes. We take Figure 8a as an example to describe the recognition of complex turning modes. Consider the two adjacent turning sequences < ， > and < ， >. Point (red point in Figure 8a) is the feature turning point with the largest turning angle in turn sequence < ， >, and (red point in Figure 8a) is another feature turning point with the largest turning angle in turn sequence < ， >. If the distance between and is less than threshold L, the adjacent two turning sequences < ， > and < ， > constitute a complex turning mode. On arriving at point , the cyclist will receive the following navigation message: "turn right ahead and then turn left". When three or more consecutive and close turn sequences are detected, such as those in Figure 8b,c, guiding users to follow the cycling trajectory proves to be a complicated task. Therefore, when the cyclist arrives to the complex turning area, the navigation message "need to turn ahead, please check the navigation route map " is sent to the user.

Cycling Trajectory-Based Sharing Navigation Algorithm
Unlike the problem of searching for optimal paths by merging multiple trajectories, as described in Ref. [19], the focus of this paper is extracting navigation characteristics from a single trajectory. The algorithm is applied to two situations: (1) By giving a user a shared cycling trajectory, other users follow the navigation route from the starting point of the trajectory to the end point of the trajectory. (2) Users directly input the start and end points, and we search all the cycling trajectories covering the start and end points from the trajectory database, and then recommend a certain trajectory to users according to some optimal criteria (shortest distance or shortest time), so that users can also arrive at the end point of the trajectory along the navigation route from the start point of the trajectory.
In the following, we provide the specific steps of the cycling trajectory sharing navigation algorithm. The cycling trajectory data collected by the provider include coordinate and azimuth angle data obtained by the positioning and direction sensors, respectively. We take Figure 8a as an example to describe the recognition of complex turning modes. Consider the two adjacent turning sequences <P 1 , P 2 > and <P 3 , P 4 >. Point P 2 (red point in Figure 8a) is the feature turning point with the largest turning angle in turn sequence <P 1 , P 2 >, and P 4 (red point in Figure 8a) is another feature turning point with the largest turning angle in turn sequence <P 3 , P 4 >. If the distance between P 2 and P 4 is less than threshold L, the adjacent two turning sequences <P 1 , P 2 > and <P 3 , P 4 > constitute a complex turning mode. On arriving at point P 1 , the cyclist will receive the following navigation message: "turn right ahead and then turn left". When three or more consecutive and close turn sequences are detected, such as those in Figure 8b,c, guiding users to follow the cycling trajectory proves to be a complicated task. Therefore, when the cyclist arrives to the complex turning area, the navigation message "need to turn ahead, please check the navigation route map" is sent to the user.

Cycling Trajectory-Based Sharing Navigation Algorithm
Unlike the problem of searching for optimal paths by merging multiple trajectories, as described in Ref. [19], the focus of this paper is extracting navigation characteristics from a single trajectory. The algorithm is applied to two situations: (1) By giving a user a shared cycling trajectory, other users follow the navigation route from the starting point of the trajectory to the end point of the trajectory. (2) Users directly input the start and end points, and we search all the cycling trajectories covering the start and end points from the trajectory database, and then recommend a certain trajectory to users according to some optimal criteria (shortest distance or shortest time), so that users can also arrive at the end point of the trajectory along the navigation route from the start point of the trajectory.
In the following, we provide the specific steps of the cycling trajectory sharing navigation algorithm. The cycling trajectory data collected by the provider include coordinate and azimuth angle data obtained by the positioning and direction sensors, respectively. The algorithm is divided into four key steps: (i) cycling trajectory data preprocessing; (ii) discovery of the turn sequences; (iii) determination of turning modes; and (iv) generation of the trajectory navigation message. Steps 1, 2 and 3 are all completed in the offline stage, and step 4 is route navigation in the online stage.
Step 1: Cycling trajectory data preprocessing The DP algorithm is used for the trajectory compression to extract feature points and eliminate staying points. Since the GPS single-point positioning error is approximately 5-10 m, the vertical distance threshold D is set to 5 m.
Step 2: Discovery of turn sequences. The turning angle threshold α and turning feature point distance threshold L are set at this step. α is set as 10 • to identify cycling in a straight line, while L is set as 30 m to adapt to different road intersection widths. Based on these two thresholds, the consecutive turning feature points should simultaneously satisfy the conditions described in Section 3.2.1. If these conditions are not satisfied, the turning sequence is considered to be over, and the discovery of the next turning sequence is continued.
Step 3: Determination of turning modes. Section 3.2.2 describes the calculation of turning angle θ, cumulative turning angles β, and the azimuth difference implemented to recognize the turning modes. The median of these three variables is taken as the turning amplitude. The navigation prompts also follow those provided in Section 3.2.2. The complex turning mode is subsequently recognized. If the distance between feature turning points with the largest turning angle in adjacent turn sequences is less than the 30 m threshold, the adjacent turn sequences constitute a complex turning mode.
Step 4: Generation of navigation messages. The proposed algorithm obtains the user's current location and outputs the corresponding navigation messages at the turns extracted from the provider's cycling trajectory. Navigation messages of normal turning modes include "turn left", "turn right" and "turn around". Complex turning navigation messages include "turn right ahead and then turn left", "turn left ahead and then turn right" and "need to turn ahead, please check the navigation route map". When the user deviates from the navigation route, the navigation message is "you have deviated from the navigation route".

Experimental Verification and Analysis
We adopt four types of smart phones to collect four trajectories, respectively (Figures 9-12). The collected trajectories all include left and right turns, as well as turning around. Compared with driving trajectories, cycling trajectories are more easily disturbed by various traffic conditions. In order to ensure the representativeness of the experimental data and verify the actual effect of the algorithm, we include several complex traffic conditions during the data collection process. The examples also include various types of interference, such as staying at traffic lights, avoiding obstacles, changing lanes, and cycling under tall buildings or viaducts. Figures 9b, 10b, 11b and 12b are partial enlarged views of the trajectory points in the circle frame of Figures 9a, 10a, 11a and 12a, demonstrating the various interferences in the data collection process of the cycling trajectory.

Extraction Results of the Turning Feature Points
The turning feature points extracted via the compression algorithm based on t jectory data should be consistent with the real turning points of actual roads. Tabl

Extraction Results of the Turning Feature Points
The turning feature points extracted via the compression algorithm based on the trajectory data should be consistent with the real turning points of actual roads. Table 1 reports the extraction of the turning feature points under different compression thresholds. When the compression threshold is set at 5-10 m, the drift and stop points in the trajectory data can be filtered out, while the extracted turning feature points are very close to the real turning points of the actual road. Figure 13 presents the turning feature point extraction under the 5 m compression threshold. real turning points of the actual road. Figure 13 presents the turning feature point extraction under the 5 m compression threshold.

Experimental Results of the Trajectory Turning Mode Determination
The strength of the proposed algorithm is its ability to correctly recognize the turning information, even when the trajectory is disturbed by avoiding obstacles, lane changing and a weak GPS signal (e.g., from cycling under tall buildings and overpasses). As the accurate extraction of trajectory feature points is closely related to the recognition accuracy of the algorithm, the experiments verify the turning mode recognition accuracy across different compression thresholds (Tables 2-5). Under different compression thresh-

Experimental Results of the Trajectory Turning Mode Determination
The strength of the proposed algorithm is its ability to correctly recognize the turning information, even when the trajectory is disturbed by avoiding obstacles, lane changing and a weak GPS signal (e.g., from cycling under tall buildings and overpasses). As the accurate extraction of trajectory feature points is closely related to the recognition accuracy of the algorithm, the experiments verify the turning mode recognition accuracy across different compression thresholds (Tables 2-5). Under different compression thresholds, the recognition accuracy of the turning modes based on the coordinate and azimuth data fusion is higher than that of just relying on coordinate data. In addition, the number of false and missing recognition instances is also lower. When the coordinate and azimuth data are combined, the recognition of the turning modes at compression thresholds of 5 or 7 m is the most consistent with the actual road conditions, and is higher than for compression thresholds of 3 or 10 m. Therefore, the compression threshold of the proposed algorithm should be set as 5 to 7 m for the sharing of cycling trajectories for navigation.
Although our algorithm does not rely on road network data for navigation, in order to verify the correctness of the algorithm, the first trajectory is taken as an example to compare the turning mode recognition results of the algorithm with the real turning modes of the actual road network ( Figure 14). The compressed trajectory data are observed to correctly reflect the turning information of the actual road network. Note that the box in Figure 14 is a result of the three very short consecutive turn sequences, constituting complex turns. Table 6 compares the results between the turning modes extracted via this algorithm and those of the actual road network. Although our algorithm does not rely on road network data for n to verify the correctness of the algorithm, the first trajectory is taken compare the turning mode recognition results of the algorithm wit modes of the actual road network (Figure 14). The compressed traje served to correctly reflect the turning information of the actual road n the box in Figure 14 is a result of the three very short consecutive turn tuting complex turns. Table 6 compares the results between the turnin via this algorithm and those of the actual road network.

Generation of Trajectory Navigation Message and Navigation Experimental Results
The navigation information of the whole trajectory can be generated according to the recognition result of the turning modes, with the compressed trajectory taken as the navigation route. Figure 15 presents the navigation messages for each part of the original trajectory. Navigation guidance will be provided twice: when the cyclist is 100 m away from the starting feature point of the turn, they will be prompted to turn 100 m ahead; when the cyclist is 10 m away from the starting feature point of the turn, they will be prompted to turn, and the specific turning mode will be given. In addition, when the cyclist deviates by more than 100 m from the navigation route, they will be informed of the deviation and they can check the navigation route map to correct the route in a timely manner. In order to verify the actual navigation effect, four volunteers with different mobile phone types were tested for four navigation routes. Table 7 reports the actual navigation results. All volunteers are able to correctly cycle along the navigation route and reach the destination via the navigation message. The average distance deviation between the actual cycling trajectory and navigation route is kept within 5 m.

Experiments in the Massive Cycling Trajectory Data
The massive quantities of experimental data come from the Sussex-Huawei L tion and Transportation (SHL) Dataset [30,31], from which we chose 50 reprehen cling trajectories. The total time of these trajectories is 19.14 h, the total distance km, and the total number of trajectory points is 68,277. Likewise, we use the pr algorithm to extract turning feature points with the compression threshold set to 5

Experiments in the Massive Cycling Trajectory Data
The massive quantities of experimental data come from the Sussex-Huawei Locomotion and Transportation (SHL) Dataset [30,31], from which we chose 50 reprehensive cycling trajectories. The total time of these trajectories is 19.14 h, the total distance is 596.3 km, and the total number of trajectory points is 68,277. Likewise, we use the proposed algorithm to extract turning feature points with the compression threshold set to 5 m. The extraction results are shown in Figure 16 below.

Experiments in the Massive Cycling Trajectory Data
The massive quantities of experimental data come from the Sussex-Huawei Locomotion and Transportation (SHL) Dataset [30,31], from which we chose 50 reprehensive cycling trajectories. The total time of these trajectories is 19.14 h, the total distance is 596.3 km, and the total number of trajectory points is 68,277. Likewise, we use the proposed algorithm to extract turning feature points with the compression threshold set to 5 meters. The extraction results are shown in Figure 16 below.  The extraction results are displayed on the electronic map platform, and we manually verified the correctness of this algorithm for turning mode identification. The recognition accuracy of the turning modes based only on the coordinate data is shown in Table 8, where we can see that over 99.2% of the turning modes can be correctly identified, the false identification rate is only about 12%, and omission identification is only about 0.8%. Generally speaking, the coordinate data collected by the position sensor can be used to correctly identify most of the turning modes, and the coordinate data have no requirement in terms of the posture of the mobile phone. However, when the satellite signal is weak, combining the coordinate data collected by the positioning sensor with azimuth data collected by the direction sensor positioning sensor can help to recognize the turning modes more accurately. To use the direction sensor, the phone needs to be fixed to the cycling vehicle. Table 8. Recognition accuracy of turning modes when the compression threshold is set to 5 m. Turn left  382  378  20  4  Turn right  329  329  30  0  Turn around  17  15  6  2  Complex turning mode  20  20 34 0

Conclusions
In the current paper, we have proposed an algorithm that employs the positioning and direction sensors built in mobile smart phones to collect coordinate and azimuth data during cycling in order to identify trajectory turning modes. Navigation messages are then generated and shared with other users based on the identified turning modes, producing a cycling trajectory-based sharing navigation framework that is independent of road network data support. Experimental results reveal the ability of the algorithm to realize route navigation by analyzing the original trajectory, without requiring the support of road network data. Thus, the proposed framework is independent of electronic map platforms. Moreover, the algorithm combines the positioning and direction sensors to improve the robustness, and considers the interference from numerous real-life situations in the cycling trajectory collection (e.g., encountering traffic lights, cycling under overpasses or tall buildings, avoiding obstacles, etc.). This ensures the accurate extraction of turning modes. Finally, the algorithm classifies common turn modes as well as several complex turn modes, providing users with correct route guidance, even for complicated traffic conditions. In summary, the proposed algorithm can realize cycling route navigation for users based on just the provider's cycling trajectory, without the need for road network data. This is suitable for cycling trajectory applications on mobile phones.
Author Contributions: Project administration, Lianhai Cao; supervision, Dongbao Zhao; writingoriginal draft, Kaixuan Zhang; writing-review and editing, Linlin Feng. All authors have read and agreed to the published version of the manuscript.