GeoJSON Web Service Based Road Assets
Management System for Surabaya City
Using Mobile GPS
Gunawan, F.X. Ferdinandus, Esther Irawati Setiawan
Department of Computer Science, Sekolah Tinggi Teknik Surabaya, Surabaya, Indonesia gunawan@stts.edu, ferdi@stts.edu, esther@stts.edu
Abstract—In this research, we have constructed road assets management system for Surabaya, the second biggest city in Indonesia. As reported in this paper, we have managed 607 assets –comprising traffic signs, traffic lights, and road marking– which are spread out at 365 different locations. The availability of mobile apps, which are equipped with camera and Global Positioning System (GPS), allows our proposed system to be implemented for road assets management system in other cities in Indonesia.
The overall system we offered has accommodated three main roles of a system: administrator, operator, and client. Administrator acts as an officer or a manager of the city transportation department. A number of operators are in charge of acquiring images and physical locations of road assets using camera and GPS of smart phones. Client has an important role in monitoring and providing valid information of damaged road assets for further follow-up maintenance by the manager.
Our research has successfully shown that Geo JavaScript Object Notation or GeoJSON-based Web Service provides several advantages in at least three different aspects. First, GeoJSON allows us to handle hierarchical data structure needed when a location might possibly have more than one road assets. Second, web service is able to support an easy distribution of data between web server and client, desktop applications, as well as various mobile apps. Third, GeoJSON supports geometric types of point and polygon, thus the process of checking point in polygon (PIP) is made possible to validate whether a road asset is indeed located on a certain track.
Keywords-Road Assets, Geographic Information System, GeoJSON, Hierarchical Data Structure, Point in Polygon.
I. INTRODUCTION
This section will discuss the background of this research, the problems that occur on the current condition, as well as the general description of the solution provided. The solution to be described is the main subject of this research.
The rapid growth of information technology undeniably creates a greater convenience of finding a location with the help of a map. Currently, location search is equipped with a tracking system from one location to the destination. The ability to digitize the Earth into a digital globe or a digital map
sparks numerous studies on the utilization of digital maps and location coordinates on the digital map.
In this study, road properties are the main focus because they are actually a very important asset, but apparently receiving rather little attention. Road properties are often damaged, stolen, or vandalized by some irresponsible culprits. Hence, the main purpose of this study is to record any data from road properties, so that each of them can be transformed into digital data and then displayed on a digital map.
The approach on the aforementioned properties requires a portable tool which can definitely be integrated with the system studied. Mobile device fulfills this requirement because it is equipped with a GPS. The device’s ability to obtain locations is used by researchers to get the data of road properties on streets. It is known that the data of a road property has its own level of complexity, whereby in a location, there can be more than one road properties. For example, for a traffic light, there are 2 kinds of lights and there is an instruction saying “traffic light applies to left turn”. This circumstance is an issue because most of the time, drivers are allowed to directly turn left in a cross junction regardless of the current traffic light. Therefore, these data should be stored in a hierarchical data structure which has a parent data with some children data.
II. CURRENT RESEARCH
This research focuses on the collection of road assets data and how they are used as an information resource for Surabaya people. Numerous researches on this topic have actually been done by other researchers across the world. Those researches focused on different parts, such as collecting data of highway assets [2,4,8], railway assets [2], road assets [9,10].
In this research, there are some similarities with the mentioned researches; for example, segmentation of assets so that they can be classified easily. Beauvais et al [2] has done asset classification in their research in order to classify assets into reconstruction, whether it is included as an asset or not. Data structure is also an important part of this study as it is related to location data. In our research, we use relational database and tree as a data representation. This representation is similar to spatial data structure in the research by Ciancia et
al[12].
Location data is highlighted in this research. The same was also done by Miller et al in their research for Road Asset Management System [10], however the data was only used to measure and manage sidewalks. In this research, the data is used to create a boundary so that road assets would not be placed in the wrong area according to the boundary.
There are several researches using image recognition to detect road signs [5]. Luo et al [9] had also employed the same technique using camera to maintain the system. The two researches mentioned could be better if the researchers added the locations of the assets, so that any defects could be fixed immediately. Sewall, Wilkie, and Lin [7] simulated the road condition virtually, in which this could also be better if he added the location data. The reason for this idea is to make the simulation more realistic and tangible.
III. SYSTEM ARCHITECTURE
In this chapter, it will be explained about the architecture of system developed. The details of the system are as shown in Figure 1.
Figure 1. System Architecture for Managing Road Assets in Surabaya City.
The following elaborates on the features of or activities performed by each component:
1. Operators
Operators will conduct a review on each property in a location through mobile applications on iOS platform. These operators will take pictures and provide additional information about road assets that are being located. Then operators will upload the data to update the existing data on the server. Figure 2 shows detailed pictures of what is done by the operator.
Figure 2. All Actions for Operator.
Figure 3. Operator Wireframe for Adding New Road Assets.
2. Administrators
Administrators will receive the reports on the condition of properties like road signs and traffic lights.
(a) 8 of 87 Available Data of Road Asset Types.
(b) Administrator Interface for Displaying Road Sign Details. Figure 4. Administrator Features to Manage Road Assets.
3. Clients
Clients are the people who can see the different types of properties on existing streets. When they are viewing the road assets, they can sort the data to be displayed.
Figure 5. Client Wireframe for Displaying All Road Assets.
IV. STORAGE STRUCTURE AND DATA DISTRIBUTION A system will not run well if the given data storage system is not optimal. Thus, besides the researched application, the data storage is also an important aspect for the researcher. The main objective in this case is so that the well-designed system will be able run properly and optimally. The database used in this study is MySQL. MySQL is one of DBMS that is free and reliable. The data stored in this study includes:
1. Property Type
There is a wide range of property types of road assets. Therefore, it is necessary to store those data in the database. 2. Property (Signs and Lights)
Property is the data obtained in the step explained in Section II. The stored data structure uses only single table, nevertheless it is able to accommodate a condition where a location has more than one road assets. As a result, each row can relate to other rows in the same table.
3. Road Segments
The storage of road segments data is used to label the roads and to limit the location of road properties recorded by the road operator; thus, geographical data errors of road assets can be minimized.
Stable database structure is not sufficient if the data is not used to display information. Therefore, a research was also conducted on the good distribution of the data stored in the database. In this study, the distribution of the data uses a web service. Web service is a software system designed to protect interoperability and interaction between systems in a network. Web service is used as a facility provided by a website. Web service stores data and information in the form of XML, JSON, REST, and many others. In this research, the structure of GeoJSON was used as a medium for the distribution of data.
GeoJSON was developed from JSON that supports the needs of geographical data communication. Because GeoJSON was developed from JSON, this section will briefly explain about JSON and later on about GeoJSON.
JSON is a communication service standard that is easy and lightweight for data exchange. JSON format is easy to be understood by human and to be parsed by computer. JSON was also chosen by researchers because it could produce stratified data to fulfil the need of hierarchical structure distribution.
All things which are supported by JSON, are also supported by GeoJSON. The difference between JSON and GeoJSON is that the key naming of each array element in GeoJSON has to follow certain guidelines. It is because the structure of GeoJSON follows the international standard published by Open Geospatial Consortium (OCG). GeoJSON has a specific function to support geographical data communication via the Internet with a standardized format. Hence, the global communication would not have limitations, since the geometry data structure has had a good standard.
Following is the example of GeoJSON result that was produced by the web service developed in this research.
Program Segment 1 – Example of GeoJSON Output {
Program Segment 1 is an example property data. Segment ‘"type": "Feature" is the type declaration of GeoJSON object which is called ‘feature object’. A ‘feature object’ must have a ‘geometry’ member and a ‘properties’ member.
Segment “geometry: {}” is used to save the location (longitude and latitude) of a property. Segment ‘"type": "Point",’ is a segment to declare geometry object type ‘point’. For the type of ‘point’, the object coordinates must be a
Segment ‘"dataproperti": [{}]’ is used to save all property type names and property type images. Segment “imageproperti” is used to save image data from property.
V. HOW TO ADD ROAD ASSETS USING POINT IN POLYGON CHECKING
This section will explain about how to add an asset. When operator adds a new road asset, the system will check whether the property location is located on a certain street.
Roads in Surabaya are not always straight. Sometimes there might be a curve at some turning points. Based on that fact, one street could possibly have several road segments.
Normally, road assets are placed on the left or the right side of the road. To validate the coordinates entered by the operator, we create several bounding boxes for each road segments. For example, Gubernur Suryo Street has 4 road segments. The coordinates points of the road segments are (-7.261868, 112.740382), (-7.262200, 112.740600), (-7.262719, 112.741082), (-7.262851, 112.741312), and (-7.263148, 112.742100). The steps to install road assets are explained in Figure 6.
Figure 6. Road Segments in ‘Gubernur Suryo’ Street.
For each road segments, we create bounding boxes. We have two coordinates for each segment, then we create a box which its width is specified beforehand and its height is the length from one coordinates to another. We have done a number of measurements to determine the best width value.
In Figure 6, there are four examples of road assets. Assets A and B are located on the right place, but assets C and D are located on the wrong place. In validating the place, we used the Point in Polygon algorithm. This algorithm calculates whether the location is inside or outside the bounding box.
VI. TESTING
This section will explain about the testing of the application which had already been implemented. The testing was done by four operators who had gone to each road sign location. Admittedly, the testing process was not free of problems. The problems encountered were:
• Internet connection problem which could give invalid GPS location.
• Images could only be captured at night because in the afternoon it could lead to traffic congestion.
• Some road signs were too damaged, resulting in invalid data obtained.
• Invalid locations could not be fixed automatically yet. We had done testing process for ten weeks. We used some locations around Central Surabaya. In the first four weeks, our testing was focused on collecting real data of road properties from 365 different locations in Central Surabaya. In the fifth week, we cooperated with some volunteers to play as an administrator, operator, and user. In the seventh week, we asked a few Surabaya residents to use our system. Based on all suggestions from those volunteers and residents, we improved our user interface and user experience to enhance our system.
TABLE I. SURVEY DETAILS OF ROAD SIGNS DATA
VII.CONCLUSION
Based on the result of three months testing, we draw some conclusions as follow:
1. Memory management is very important because in property management, the data input is huge. If the memory is not properly managed, the application will operate slower. 2. Image quality setting is essential because by doing so, the
photo can be adjusted to be rather small in size, yet high in clarity.
3. Map zooming level does not fully support the display of some adjacent properties, hence some properties were considered as located in one location.
4. GPS accuracy is highly dependent on signal strength and cellular provider used in the mobile device. Each location of road assets could be easily stored using GPS.
5. Tree-shaped data storage structure is very helpful in handling various problems, such as the existence of a number of properties in one location.
6. Point in polygon algorithm is used to verify location data. As a consequence, we saved each coordinate for the calculation.
7. JSON data structure is a sophisticated answer for data distribution. In fact, there are a lot of developers using JSON as an input for their map application
ACKNOWLEDGMENT
This research was financially supported by Kemenristekdikti (Ministry of Research, Technology and Higher Education) Republic of Indonesia through Hibah Bersaing (Competitive Research Grant) for the second fiscal year, 2016, contract No. 069/SP2H/P/K7/KM/2016 dated 25 April 2016 and 015/LPPM/SP3H/V/2016 dated 17 May 2016. We thank you for anonymous reviewers who gave input for improving this research.
REFERENCES
[1] S. L. Pearce and H. A. Ratcliff, “Recent Developments in the Street Lighting of Manchester,” Journal of the Institution of Electrical Engineers, vol. 50, pp. 596-634, Mar 1913.
[2] J. C. Beauvais, J. C. Lam, M. J. Lee, V. C. Reis, Y. Y. Haimes, and J. H. Lambert, “Asset Management for Virginia Highways and Roads,” Proceedings of the 2003 Systems and Information Engineering Design Symposium, pp. 269-274, April 2003.
[3] H. Guler and S. Jovanovic, “The Application of Modern GIS Technology in the Development of Railway Asset Management Systems,” IEEE International Conference on Systems, Man and Cybernetics, vol. 5, pp. 4153-4158, October 2004.
[4] K. Ananraya and V. Ammarapala, “The Development of Highways Assets Management System,” 7th International Conference on Service Systems and Service Management (ICSSSM), pp. 1-6, June 2010. [5] P. Foucher, Y. Sebsadji, J. -P. Tarel, P. Charbonnier, and P. Nicolle,
“Detection and Recognition of Urban Road Markings Using Images,” 14th International IEEE Conference on Intelligent Transportation Systems (ITSC), pp. 1747-1752, October 2011.
[6] Rabia, E. S. Ali, N. Ehsan, and I. Mirza, “Formulation of Road Asset Management System of Pakistan,” International Conference on Remote Sensing, Environment and Transportation Engineering (RSETE), pp. 8281-8284, June 2011.
[7] J. Sewall, D. Wilkie, and M. C. Lin, “Interactive Hybrid Simulation of Large-Scale Traffic,” ACM Transactions on Graphics (Proceedings of ACM SIGGRAPH Asia 2011), vol. 30, December 2011.
[8] W. E. Hatcher, A. P. Whittlestone, J. Sivorn, and R. Arrowsmith, “A Service Framework for Highway Asset Management,” Asset Management Conference 2012 (IET & IAM), pp. 1-6, November 2012. [9] X. Luo, X. T. Ren, Y. Li, and J. J. Wang, “Mobile Surveying System for
Road Assets Monitoring and Management,” 7th IEEE Conference on Industrial Electronics and Applications (ICIEA), pp. 1688-1693, July 2012.
[10] S. Miller, P. Scott, S. Cooper, P. Brown, P. Ingram, and H. Chalmers, “Road Asset Management Systems,” Asset Management Conference 2012 (IET & IAM), pp. 1-6, November 2012.
[11] S. J. Wilson, “Data – To Capture or Not to Capture?,” Asset Management Conference 2012 (IET & IAM), pp. 1-4, November 2012. [12] V. Ciancia, S. Gilmore, D. Latella, M. Loreti, and M. Massink, “Data
