Publication Repository E2 1C.2
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
[email protected], [email protected], [email protected]
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
IEEE Copyright e.g. 978-1-4673-8139-0/16/$31.00 ©2016 IEEE
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.
This module is the main module conducted by operators. If
an operator is already at the location, that operator can click
“Add Property” button. Next, a map will automatically appear
with a pin on operator’s current location. Operator can make
adjustments by dragging and dropping the pin to the right
location. Following this, operator then capture images and
input the details of the property to be stored in the database. To
keep the database updated, operator can perform the same
action with additional data. If operator removes a property data,
the data will not actually be deleted, instead its status will be
put as inactive. Inactive property data will not be displayed on
the screen.
2. Administrators
Administrators will receive the reports on the condition of
properties like road signs and traffic lights.
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.
(a) 8 of 87 Available Data of Road Asset Types.
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.
(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.
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.
Figure 5. Client Wireframe for Displaying All Road Assets.
To minimize error in inputting location data of a road asset,
Point in Polygon (PiP) is used. PiP is an algorithm used to
detect whether the placement of a road asset is correct or not.
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
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [-7.290305, 112.736417]
},
"properties": {
"dataproperti": [{
"namajenisproperti": "Dilarang Parkir",
"imagejenisproperti": "http://localhost/
Project/iroad/jenisproperty/1.jpeg"
}, {
"namajenisproperti": "Dilarang Berhenti",
"imagejenisproperti": "http://localhost/
Project/iroad/jenisproperty/2.jpeg"
}],
"imageproperti": "http://localhost/Project/
iroad/property/1_MLR.jpeg"
}
}
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
position.
Segment "properties": {}’ is used to save all data of a
geometry object. In the program segment example above,
segment ‘"properties": {}’ has two values or members, those
are “dataproperti” and “imageproperti”.
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
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.
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.
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.
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.
•
Invalid locations could not be fixed automatically yet.
The following is the sample result of the testing done. The
result given in this part is only the result from one operator
testing.
TABLE I.
SURVEY DETAILS OF ROAD SIGNS DATA
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]
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.
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
verification for collective adaptive systems: spatial model-checking of
vehicle location data,” IEEE Eighth International Conference on SelfAdaptive and Self-Organizing Systems Workshops (SASOW), pp. 3237, September 2014.
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
[email protected], [email protected], [email protected]
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
IEEE Copyright e.g. 978-1-4673-8139-0/16/$31.00 ©2016 IEEE
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.
This module is the main module conducted by operators. If
an operator is already at the location, that operator can click
“Add Property” button. Next, a map will automatically appear
with a pin on operator’s current location. Operator can make
adjustments by dragging and dropping the pin to the right
location. Following this, operator then capture images and
input the details of the property to be stored in the database. To
keep the database updated, operator can perform the same
action with additional data. If operator removes a property data,
the data will not actually be deleted, instead its status will be
put as inactive. Inactive property data will not be displayed on
the screen.
2. Administrators
Administrators will receive the reports on the condition of
properties like road signs and traffic lights.
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.
(a) 8 of 87 Available Data of Road Asset Types.
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.
(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.
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.
Figure 5. Client Wireframe for Displaying All Road Assets.
To minimize error in inputting location data of a road asset,
Point in Polygon (PiP) is used. PiP is an algorithm used to
detect whether the placement of a road asset is correct or not.
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
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [-7.290305, 112.736417]
},
"properties": {
"dataproperti": [{
"namajenisproperti": "Dilarang Parkir",
"imagejenisproperti": "http://localhost/
Project/iroad/jenisproperty/1.jpeg"
}, {
"namajenisproperti": "Dilarang Berhenti",
"imagejenisproperti": "http://localhost/
Project/iroad/jenisproperty/2.jpeg"
}],
"imageproperti": "http://localhost/Project/
iroad/property/1_MLR.jpeg"
}
}
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
position.
Segment "properties": {}’ is used to save all data of a
geometry object. In the program segment example above,
segment ‘"properties": {}’ has two values or members, those
are “dataproperti” and “imageproperti”.
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
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.
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.
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.
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.
•
Invalid locations could not be fixed automatically yet.
The following is the sample result of the testing done. The
result given in this part is only the result from one operator
testing.
TABLE I.
SURVEY DETAILS OF ROAD SIGNS DATA
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]
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.
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
verification for collective adaptive systems: spatial model-checking of
vehicle location data,” IEEE Eighth International Conference on SelfAdaptive and Self-Organizing Systems Workshops (SASOW), pp. 3237, September 2014.