*3.2. LOD*

The dynamic vehicle information of the proposed system is retrieved via the API of the New Taipei City Government open data platform through R language. The API updates data once every five minutes, randomly returns a record with eight fields of real traffic data once at a single sensing point, and transmits data in the JSON format, as shown in Figure 2. Each field has the following corresponding meanings.


**Figure 2.** Dynamic vehicle data (Origin URL: https://data.ntpc.gov.tw/od/detail?oid=875D5555-A881-4 561-8E9D-93B96C959384).

This study only stored the relatively important dynamic vehicle data. Figure 3 shows the traffic data extraction concept, as developed for the proposed LOD subsystem. It is mainly based on road direction (vsrdir) as the water shed, access to a single kind of vehicle (carid), and a single road (vsrid). The corresponding cloud database stores the LOD, based on the principle of low host load and saving database space. Figure 4 shows the open data captured by the subsystem at random time intervals. Based on the error message, meaning that the sensors cannot frequently read the traffic flow that occurs on the open data platform, the subsystem filters and analyzes the data through the program loop of R language, which captures and links the vdid, longitude, and latitude of the vehicle static data of the traffic sensing endpoint. Figure 5 illustrates the linked data content. The LOD are captured by the vehicle static information of the open information platform through R language and stored in the cloud database. Figure 6 shows the fragment program. The API updates data once a day. The web application automatically retrieves the database every five minutes and presents it on the webpage, thus greatly improving the real-time accuracy of the proposed system.




**Figure 4.** Example of reading real open data at a single time.


**Figure 5.** Linked static vehicle data. "雙向" is two-way; "單向" is one-way; The rest of the Chinese characters are the addresses of the corresponding road sections.

#### *3.3. Establishment of Cloud Server and Corresponding Databases*

The proposed system uses Microsoft Azure cloud services to set up a web server, as installation in the cloud can reduce the consumption of physical equipment. The system service can be diversified and open, and the website server is not restricted by physical attacks, such as a power failure in the computer room, network interruption, etc. In the case of power failure and network interruption, it can also quickly switch to hosts in other regions through cloud services to continuously maintain the adequacy rate of this cloud system, thus improving the practicability and sustainability of the cloud system. The cloud database stores the data of the New Taipei City Government, including open information, report status information, reporter information, and related information used by the corresponding subsystem, such as web applications and the user road condition reporting subsystem. When the users open the system, the system displays their longitude and latitude, as obtained through the Google Geolocation API on the system webpage, and converts it to the corresponding physical address. When users want to report new road condition information, such as information regarding congestion status, they can log the current situation information through the user road condition reporting subsystem, and other drivers and police units can know the situation and take follow-up actions. The positioning function used in this subsystem adopts HTML 5 to obtain the position longitude and latitude. Table 2 presents the description of the main parameters of GetPosition. However, as a cloud database has the advantage of flexibility, it can select the most suitable service content according to the current requirements, thereby reducing costs. The disadvantage lies in the safety problem; however, as traffic information is not personal data and is part of public information, the information service can be taken as the first priority.


**Table 2.** Description of main parameters and functions of GetPosition.

#### *3.4. User Reporting Mechanism on Road Conditions*

At present, when traffic-related information systems in Taiwan are confronted with traffic emergencies, most people would call the police broadcast hotline, while people on the national highway would call the 1968 traffic voice service line for traffic inquiries, traffic notifications, road rescues, and other services. In addition, some road users often use the Google Maps application to check traffic information. However, neither the system nor the mobile phone application has a real-time information user reporting function for traffic emergencies. The establishment of the road condition user reporting mechanism requires users to enter the member mode in order to check the identity of the reporter and ensure the accuracy of the reported data. This can improve the system's ability to present the comprehensive real-time traffic data to other road users, and further improve the real-time information deficiency faced by government units in making decisions when considering road condition assessment. Figure 7a shows the operating flow of the road condition user reporting mechanism of the proposed system. First, member registration is required to ensure that the users are road users. As mentioned above, when users encounter road congestion (e.g., accidents, heavy traffic, processions, control, etc.) while driving on a road section and their path is blocked, the users can open the road condition reporting function of the system to add report information (e.g., congestion type and current situation). After completing the corresponding report form, the report form can be sent out and stored in the cloud database of the system. The processing flow of the added report information is shown in Figure 7b. Subsequent responsible units, such as police units and their related responsible units, receive the report information and then dispatch manpower to the location for road condition elimination in a more real-time and accurate manner, thereby solving the problems efficiently.

**Figure 7.** Road condition user reporting mechanism and processing flow chart: (**a**) operation process of road condition user reporting mechanism; (**b**) processing flow chart of newly added information.

### **4. System Presentation and E**ffi**ciency Analysis**

#### *4.1. System Presentation*

As mentioned above, the proposed system uses intelligent handheld devices and computer devices to present an intelligent traffic assistant agent using GPS and LOD technology with the optimal page size. The real-time display images include real-time information, a real-time image list, endpoint analysis information, and real-time reporting, which are listed and explained as follows. The web application of the agent presents all the operational functions of the proposed system. When the users turn on the system, the system takes the longitude and latitude of the users' location and presents it on a map through the GPS function of the intelligent handheld device held by the users, and then displays the "real-time status" data, such as the green color indicating smooth conditions and red indicating congested road conditions. Figure 8 shows the system execution screens, as opened by a computer and a handheld device, respectively.

**Figure 8.** Real-time traffic information displays for a (**a**) computer and (**b**) mobile phone. In this step we take the longitude and latitude of the user's location and present it on a map through the GPS function of the intelligent handheld device held by the user, and then, display the "real-time status" data, such as the green color indicating the smooth conditions and red indicating congested road conditions.

Regarding the traffic "real-time image" function, the proposed system combines many supported Google Chrome browsers and Apple Safari browsers and matches RWD web page technology for seamless connection to achieve a cross-platform and diversified traffic assistant agency system. When the users open this system, the system uses the GPS function of the intelligent handheld device held by the user, which reads the users' location and displays the nearby monitor screen, and then verifies the road section. Figure 9 shows the execution screens of a computer and a handheld device, respectively; users can click the "view" hyperlink to display the real-time image of the endpoint; users can also click endpoint number 3 to show the real-time image of Zhongzheng Road and Zhongshan Road. The computer and handheld device displays are shown in Figure 10 (capture time: 7 April 2019).

**Figure 9.** Real-time traffic image (Take the Tamsui District, New Taipei City, Taiwan as an example) displays for a (**a**) computer and (**b**) mobile phone. In this step we use the GPS function of the intelligent handheld device held by the user, which will read the user's location and display the nearby monitor screen, and then, look at the road section.

**Figure 10.** Real-time traffic image displays for endpoint number 3 for a (**a**) computer and (**b**) mobile phone. In this step we Click the "View" hyperlink to display the real-time image of the endpoint; for example, click endpoint number 3 to show the real-time image of Zhongzheng Road and Zhongshan Road.

As mentioned above, the "endpoint information" of this system is extracted from the dynamic vehicle information of the New Taipei City open data platform as the real-time data of the sensing endpoint. Due to the poor contact of the reported data of some sensing endpoints, the inability to sense data, and other reasons, the data is incomplete. In this study, JSON is retrieved through R language and the data content required for screening is automatically retrieved and stored in the cloud database, which is then presented through the traffic assistance agent web application. Users can use the intelligent handheld devices to view the most real-time endpoint road condition information (including speed and vehicle detection). Figure 11 shows the execution screens of a computer and handheld device, respectively.

**Figure 11.** Real-time data displays of endpoint information for a (**a**) computer and (**b**) mobile phone. The "endpoint information" of this system is extracted from the dynamic vehicle information of the New Taipei City Open Data Platform as the real-time data of the sensing endpoint, including forward and reverse road information.

Based on the above, as sensing endpoints often fail to sense data and report error messages, the proposed system uses the longitude and latitude positions of the endpoints of the vehicles not in motion and the vdid of the sensing endpoints on the New Taipei City open data platform. The obtained data are filtered through R language, and the data of each sensing endpoint is updated in the system's cloud database. If there are additional sensors, the system stores them in the cloud database. The users can view the "sensing endpoint information" of each sensed endpoint through the system, so that government information can be openly and transparently displayed. At that time, the users or government work units can use a smart handheld device to view and attend to the endpoint to carry out relevant work services, such as inspection and repair. Figure 12 shows the execution screen of the system opened by a computer and a handheld device, respectively. Users click the "navigation" hyperlink to open the icon of the Google Maps display endpoint. Taking endpoint number 65000V008130 as an example, the displays of the computer and handheld devices are shown in Figure 13.

Regarding the "road condition reporting function", after logging into the system, when users arrive at an accident emergency site, their intelligent handheld device can read the longitude and latitude of their location through the built-in GPS function and present it in real time on the reporting page. If the users click on the relevant information (e.g., category, event, date, and time) of the emergency site, the system will immediately store it in the cloud database, and road users behind them can see the information. The police and public works units can arrive at the site promptly to eliminate the reported traffic condition, thus shortening the congestion time of the traffic section. Figure 14 shows the execution screens opened for a computer and a mobile phone, respectively, to complete the "add road condition reporting information".

**Figure 12.** Sensing information displays of endpoints for a (**a**) computer and (**b**) mobile phone. The user will view the "sensing endpoint information" of each sensed end through the system, at that time, the user or government work unit will hold an intelligent handheld device to view and attend the endpoint to carry out relevant work services.

**Figure 13.** Navigating to endpoint number 65000V008130. Displays for a (**a**) computer-side and (**b**) mobile phone. The user will click the "navigation" hyperlink to open the icon of the Google Map display endpoint. Taking endpoint number 65000V008130 as an example.

After being verified as a member and completing the "add road condition reporting information", the "history analysis" page of the system obtains that reporting information through the cloud database, as shown in Figure 15; that is, clicking on the navigation function of the page will open the icon of the Google Maps display endpoint.

The proposed system establishes a back-end management system for user reporting information, which is mainly responsible for management, such as report information resolution, member management, real-time image settings, etc. The identities of users are visitors, registered members, and administrators. The hierarchical information of relevant identities is detailed in Table 3. Visitors only have the function of viewing information, and cannot use any of the reporting functions. Registered members can enter the member area to add new reporting information. Administrators can enter the management area, browse and modify all member data, and delete members. Figure 16 shows the page of the back-end system management.

**Figure 14.** Road condition user reporting function displays for a (**a**) computer and (**b**) mobile phone. After logging into the system, when a user arrives at an accident emergency site, their intelligent handheld device can read the longitude and latitude of their location through the built-in GPS function, and present it in real time on the reporting page to complete add road condition reporting information.

**Figure 15.** History analysis page displays map distribution of road reporting information and popular congestion locations for a (**a**) computer and (**b**) mobile phone. History analysis page of the system will obtain the return information through the cloud database; that is, clicking on the navigation function of the page will open the icon of the Google Maps display endpoint and go there.

**Table 3.** Hierarchical authority list for system members.


Legend: "✓" means to have this function; while "✗" means none.

**Figure 16.** Back-end system management page.

The reason for the hierarchical management of the system's modification of report information is that different authorities and responsible units (e.g., police units, public works units, etc.) have slightly different authority. For example, the real-time image setting is within the jurisdiction of police units. Table 4 and Figure 17 present the hierarchical authority table of power and the responsible units, the page of power, and responsible unit management area in the system. In addition, the public works unit, police unit, and back-end management can add and modify the information related to the road condition report. Police units and back-end management can add and modify settings related to real-time imaging devices. Finally, back-end management has all the rights of the system, and can delete additional settings, such as members.


Legend: "✓" means to have this function; while "✗" means none.


**Figure 17.** Authority unit management page.

#### *4.2. Performance Analysis*

The following comparisons and experiments involved users from related departments (Department of Information and Communication Engineering), unrelated departments (Department of Business Management), and users from the middle–high age group (over 45 years old). There were ten persons in each group, and the three groups were used as a reference frame for analysis. All comparisons and evaluation results were based on opinions, for which there was 75% or greater agreement in the three groups, showing that the majority of the subjects were in agreement.

The main comparison objects of this system are four traffic information systems related applications, namely Police Broadcast Real-Time Traffic, Road Condition Autotoll, Real-time Traffic Image—RoadCam, and New Taipei City Advanced Traveler Information System. The following experiment presents the analysis of data accessibility and system performance. This is the first condition for a user-friendly interface of information systems—rapid response information accessibility. The content of the first experiment is to explore the data accessibility analysis of the system, as well as its related systems. This study compared the following items: open real-time information, real-time images, road condition reporting, real-time weather, and other information for analysis and comparison. Table 5 presents the comparison between the proposed system and its related applications for the corresponding information, as obtained by the number of clicks with the same target. The "X" in the table indicates that the system does not have this function, while the numbers in the table means the number of clicks for the corresponding data. This study performed the click count experiment in real time, and recorded the data for analysis and comparison with other applications. This study developed a total of eight comparison items for the average number of clicks to perform experiments, and developed Equation (1), where S is the comparison system, K is the comparison system number, n is the number of system comparison items, Click is the number of clicks of the comparison item, x denotes that the comparison item of the system has no such function and is not included in the calculation, and Nx is the number of such functions available. In the end, the data acquisition clicks of

the proposed system averaged 1.6 times, while both the RoadCam and New Taipei City Advanced Traveler Information System averaged 1.8 times, and the remaining Police Broadcast Real-Time Traffic and Autotoll both averaged more than 2 times. It is obvious that the proposed system exhibits excellent performance in the accessibility of the information acquisition interface, which is the first condition for building an effective information system with user-friendly interfaces.

$$\text{Average}\_{\text{S}} = \begin{cases} \sum\_{i \notin \text{x}}^{\text{n}} \text{Click}\_{i} \\ \left( \frac{\text{n} - \text{N}\_{\text{x}}}{\text{n} - \text{N}\_{\text{x}}} \right) \end{cases} \tag{1}$$

The second experiment is the content of system operating environment and user experience analysis. This is also one of the important topics for constructing contemporary information systems with user-friendly interfaces. In order to explore the function test of this system, three categories are planned: positioning, multiplatform, and user experience, including eight items for function comparison (see Table 6 for details). The comparison objects of this experiment are the four systems mentioned above. Through experimental tests, the proposed system can accurately obtain the current location, both indoors and outdoors, with a handheld device with the GPS function, and the other two can also obtain the current location. The system can be used normally in multiplatform browsers. At present, there are only IOS and Android platforms in Autotoll, and there is no computer version. Finally, the user experience part of the comparison system is discussed. The proposed system uses the Microsoft Azure web server and database applications. The traffic can be automatically allocated to optimize the operation of the system, and the multiplatform RWD responsive webpage technology [54] is adopted. Thus, users do not have to repeatedly learn the webpage version or the mobile phone version of the proposed system.

The third experiment is the content and function balance of the important items of the interface design. The design preference to importance ratio (DIR) (Equation (2)), as proposed by Ha [55], is taken as the design principle of the human–machine interface (HMI) of this system. The HMI is ideal when combined with the balancing index (BI) (see Equation (3)) to define the user interface. In short, if BI is zero, all the HMI elements in the interface design are balanced and perfect. Its physical meaning is that the HMI design satisfies the principle of the design preference for importance, and the interface operation of the system is more consistent with user demand:

$$\text{DIR}\_{\text{ijk}} = \frac{\frac{\text{DP}\_{\vec{\eta}}}{\frac{\sum\_{i=1}^{n} \text{DP}\_{\vec{\eta}}}{\sum\_{i=1}^{n} \text{I}\_{\vec{\text{ik}}}}}{\frac{\text{I}\_{\vec{\text{ik}}}}{\sum\_{i=1}^{n} \text{I}\_{\vec{\text{ik}}}}} \tag{2}$$

$$\text{BI}\_{\text{jk}} = \frac{\left| \sum\_{i=1}^{n} \log\_{10} \text{DIR}\_{\text{ijk}} \right|}{\text{n}} \tag{3}$$

where DIRijk is the DIR of design attribute j and importance attribute k of HMI interface element i. DPij is the design preference of design attribute j of HMI interface element i. Iik denotes design importance k of the importance attribute of HMI interface element i. BIjk is the balance index of design attribute j and importance attribute k, while n is the total number of HMI interface elements.


**Table 5.** Analysis results of data acquisition accessibility.


A five-scale evaluation scheme is used to evaluate each design preference (DPij). The design preferences include very good, good, moderate, weak, and very weak, and their corresponding values are five, four, three, two, and one, respectively. Table 7 displays the evaluation of the HMI elements in our design attributes, as well as the corresponding informational importance of the proposed agents, as evaluated using the analytic hierarchy process [55]. Table 8 illustrates the evaluation results of DIR with average BI = 0.012534 (BI should approach zero for the best balance) of the proposed agents. "Needs to improve a little bit" means that the proposed system interface design must be slightly adjusted, but will not affect the operations of the proposed system. The verification results show that the human-machine interfaces of our proposed agents can meet important design preferences and provide approximately optimal balance.


**Table 7.** Evaluation of human–machine interface (HMI) elements and their corresponding importance.

**Table 8.** Evaluation results of design preference to importance ratio (DIR) where balancing index (BI) = 0.012534.


Finally, this study did not analyze the correctness and satisfaction of the information provided by the proposed system because it adopted the LOD of government units, which provide accurate and reliable information. Moreover, this study developed an instant image-based information system that is user-friendly and offers nearly perfect design interfaces to present the LOD of government units. The answer to the above question is, hence, self-evident.

#### **5. Conclusions and Discussions**

Based on GPS and LOD technology, this study developed a multiplatform, cloud-based, and instant image-based traffic assistance agent with user-friendly interfaces, which provides various functions, including real-time information, real-time images, endpoint analysis information, and real-time user reporting. It also has quite good user experience in the system interface design, and the system files and required databases are cloud-based. On a smart handheld device with Internet connection, users can access the proposed system and the condition reporting system. The proposed system does not have any demand on the device capacity, as all systems are developed on a cloud-based smart traffic assistance system. The comprehensive system operation and presentation to performance comparison confirmed that the proposed system has excellent accessibility to the information acquisition interface and approximately optimal balance of the important items of the interface design. Moreover, due to the application of the Microsoft Azure web server and database, traffic can be automatically allocated to optimize system operation. In addition, this study adopted RWD responsive webpage technology, which makes it easier for users to use various devices without having to learn the relevant interfaces of the proposed system.

Although the proposed system has been successfully combined with Microsoft Azure cloud services to achieve cloud-based, instant image-based, and traffic LOD of government units, there are still many unfinished, missing, and yet to be improved areas, which are listed and described as follows:


**Author Contributions:** The research article was completed by two authors, F.-H.C. and S.-Y.Y. F.-H.C. and S.-Y.Y. jointly designed the overall architecture and related algorithms, and also conceived and designed the experiments, however S.-Y.Y. coordinated the overall plan and direction of the experiments and related skills. F.-H.C. and S.-Y.Y. contributed analysis tools and also analyzed the data. F.-H.C. performed the experiments, and S.-Y.Y. wrote this paper and the related reply. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research is partly sponsored under grants 106-2221-E-129-008 and 107-2632-E-129-001 by the Ministry of Science and Technology, Taiwan.

**Acknowledgments:** The authors would like to thank Yu-Wei Wu for his assistance in earlier system implementation and preliminary experiments. The authors feel deeply indebted to the Department of Electrical Engineering and Department of Information and Communication, St. John's University, Taiwan, for all aspects of assistance provided. All authors have read and agreed to the published version of the manuscript.

**Conflicts of Interest:** The authors declare no conflict of interest.
