Geo-Sensor Framework and Composition Toolbox for E ﬃ cient Deployment of Multiple Spatial Context Service Platforms in Sensor Networks

: Geo-sensor is the term used for the deployment of a wireless sensor network (WSN) in a real environment, which can be a hideous task due to many inﬂuential variables in a given environment. The spatial context of a sensor in a smart environment can be of huge signiﬁcance and can also play an important role in improving the smart services provision. In this work, we propose a DIY geo-sensor framework and data composition toolbox for the deployment of sensors data in smart IoT environments along with geographical context. A geo-sensor framework is deployed, which enables the registration of multiple geo-sensor networks by providing multiple geo-sensor platforms. The framework’s logic is based on the combination of a geo-sensor service registry, geo-sensor composition toolbox, and geo-sensor platforms. A geo-sensor platform provides the content to the toolbox, enabling relaxed real-time geo-sensor data management. Our proposed work is two-fold. Firstly, we propose the design details for the geo-sensor framework and composition toolbox. The proposed design for the geo-sensor framework aims to provide a DIY platform for multiple geo-sensor networks and services deployment, giving access to multiple users resulting in reuse of resources and reduction in deployment costs by avoiding duplicate deployments. Secondly, we implement the proposed design based on RESTful web services and SOAP web services. Performance comparison analysis is then performed among the two web services to ﬁnd the best suited implementation for given scenarios. The results of the performance analysis prove that RESTful web services are the better choice for ease of implementation, access, and light-weightiness. on the geo-sensor framework. In Section 4, the implementation of the proposed framework is


Introduction
A system designed to integrate and display the spatial data of "things" is called a geographical information system (GIS) [1]. GIS also enables the user to store, edit, analyze, and share the geographical data of a given entity. GIS represents data in a useful and meaningful way for users to understand and utilize, also enabling the users to process large amounts of data. Wireless sensors networks (WSN) produce large amounts of data, which is processed for different purposes and intelligent decision making. Integrating the WSN with GIS can make the task of analyzing the data gathered by WSN more evocative for the users to process and analyze [1].
Geo-sensor is the deployment of a wireless sensor network (WSN) in a real environment, which can be a hideous task due to many influential variables in a given environment. A wireless sensor network is a combination of spatially distributed wireless devices that are deployed to monitor physical or environmental conditions such as temperature, light, sound, and humidity. These wireless devices have sensors to collect data from the surrounding environment and pass the data onto some main location. Each wireless device also has a transmitter and a receiver, which are used to communicate wireless devices have sensors to collect data from the surrounding environment and pass the data onto some main location. Each wireless device also has a transmitter and a receiver, which are used to communicate with other wireless devices or gateways within a network. The gateway, also known as middleware, transfers the sensed data to the main location, which logs in the data, and the data is then available to view, process, and analyze via the user interface [2].
Physical sensors from sensor networks are uploaded as virtual sensor objects with sensor profiles created and stored in the databases. These sensor profiles are then used to extract the sensors' types, values, and environmental scenario contexts along with the geographical contexts based on the physical locations and location based constraints and parameters. The geo-sensing services are then created by combining the sensors' contextual information and geographical contextual information; based on each systems requirements and scenarios. Figure 1 shows the conceptual overview of the geo-sensor networks' services formation. Geo-sensor applications and services are of huge significance and are applied to multiple scenarios and environments based on the contextual information. We can conclude from our literature review study, presented in Section 2, that little effort is made in proposing standard designs for geo-sensor frameworks for multiple geo-sensor network deployment and service creation; where the user gets the freedom of uploading their networks based on multiple locations and contextual information and creating and using the services accordingly.
Such systems where more freedom is given to the users are termed as DIY (do-it-yourself) systems. Recently, DIY approaches for IoT (Internet of Things) applications have gained much hype. The concept of IoT can be simply put as connecting "things", such as objects and entities, to the internet and making them smart. The concept of DIY was first proposed in 2011 [3], and multiple approaches have been proposed in recent years for DIY virtual services in IoT networks [3][4][5][6][7][8][9][10]. Specifically in the geo-sensing category, not much work has been done for DIY implementation except for one recently started project named as community-centered urban sensing (CCUS) and DIY sensing devices [11], which collects environmental sensing data, visualizes the data and aims to develop customized digital infrastructure for empowering communities for better sensing their Geo-sensor applications and services are of huge significance and are applied to multiple scenarios and environments based on the contextual information. We can conclude from our literature review study, presented in Section 2, that little effort is made in proposing standard designs for geo-sensor frameworks for multiple geo-sensor network deployment and service creation; where the user gets the freedom of uploading their networks based on multiple locations and contextual information and creating and using the services accordingly.
Such systems where more freedom is given to the users are termed as DIY (do-it-yourself) systems. Recently, DIY approaches for IoT (Internet of Things) applications have gained much hype. The concept of IoT can be simply put as connecting "things", such as objects and entities, to the internet and making them smart. The concept of DIY was first proposed in 2011 [3], and multiple approaches have been proposed in recent years for DIY virtual services in IoT networks [3][4][5][6][7][8][9][10]. Specifically in the geo-sensing category, not much work has been done for DIY implementation except for one recently started project named as community-centered urban sensing (CCUS) and DIY sensing devices [11], which collects environmental sensing data, visualizes the data and aims to develop customized digital infrastructure for empowering communities for better sensing their environments, and voicing their opinions by Appl. Sci. 2019, 9, 4993 3 of 21 taking part in feedback process. The project is still limited in visualization and analysis of sensing data and in its preliminary stages.
Hence, a DIY geo-sensor framework for the deployment of geo-sensor networks, where multiple users could upload their geo-sensor platforms and extend access of use to other users, can pave ways for unlimited potential in geo-sensor applications and research fields.
In this work, we propose a geo-sensor framework that can be used by multiple clients to deploy their own geo-sensor networks, bind their sensor objects to desired locations based on DIY, generate geo-sensor services for the uploaded networks, and manage the services with a geo-sensor composite toolbox. The availability of such a platform will allow the ease of deployment and management for the geo-sensor networks and also the reuse of geo-sensor services. The deployed geo-sensor platform and its services can be reused by authorized users in different scenarios, with the online availability of the geo-sensor framework. This also reduces the deployment cost in scenarios where such deployed networks and services can be reused, as an alternative to additional deployments. It will also reduce the deployment redundancy. The proposed work offers the following novelty points as The multiple spatial context service platforms use the sensor profile information and geographical context of the service to create geo-sensor services. We present the detailed system design for the deployment of geo-sensor framework, geo-sensor composition toolbox, and geo-sensor multiple spatial services platforms for the wireless sensor networks. The proposed system is implemented using both the RESTful web services and SOAP web services. RESTful web services allocate URI (Uniform resource identifier) to each resource and use basic CRUD operations over HTTP for making the interface uniform throughout and are simpler to implement. The rest of the paper is divided as follows; Section 2 gives an overview of related work. Section 3 presents the system design for a geo-sensor framework and multiple platforms deployment based on the geo-sensor framework. In Section 4, the implementation of the proposed framework is presented. In Section 5, we give a performance analysis of a system based on system queries and access times, and Section 6 concludes the paper.

Literature Review
The proposed work falls under the category of contextual sensing. All physical objects (e.g., sensors, actuators, things) or human beings have some context attached to them in a given scenario. The context can be defined as "any information that can be used to characterize the situation of an entity [12]. The context of an entity can be either external or internal; external contexts are perceived from the physical environment, such as sensing values from sensors or the location from GPS, whereas internal contexts are customized individual level contexts within a system [13]. In our proposed work, we focus on the external context as our scope is limited to geo-sensing services.
One of the subcategories for applications of geo-sensors is the spatiotemporal contexts based services. The term spatiotemporal means belonging to both space and time; hence, the application of spatiotemporal is not just limited to the extraction and use of physical locations contexts [14,15]. Many studies have been presented based on the applications of spatiotemporal with other attributes added to the given physical locations based on the specific time; such as effect of weather conditions at a given time at a location, such as rainfall on the mobility pattern in a city [16,17], or the effect of environmental conditions, such as air quality on the traffic flow within a city [18]. The work presented in [19], discusses and analyzes the contextual sensing based on integrating contextual information with human and technical geo-sensor information for smart cities. The authors highlight the significance of contextual information and discuss the challenges regarding spatiotemporal contextual information. Three groups of sensors are discussed along with the three dimensions of sensing as data generation, geographic phenomena, and type of sensing. The authors aim to explore the use of geo-sensing capabilities and contextual information integration for the future development of smart cities.
Very few studies have presented and proposed the design and implementation of a GIS toolbox. The work presented in [60] proposes an adaptive GIS toolbox for hydrological modeling. In order to increase reusability and portability, the modules are programmed in an object-oriented fashion. The tasks of modeling elements of the hydrological cycle can be done using the toolbox, and it also supports different temporal and spatial scales. The presentation of the spatial, temporal, and geographical data is done using GRASS. The work presented in [61] proposes a landscape genetics GIS toolbox. It maps the genetic landscapes and summarized multiple genetic landscapes. Genetic diversity can be visualized using these tools. Together, these tools create genetic landscape surfaces directly from tables containing genetic distance or diversity data and sample location coordinates, greatly reducing the complexity of building and analyzing these raster surfaces in a Geographic Information System. The work in [62] presents the principal strategies of object-oriented analysis, discusses how the combination with fuzzy methods allows implementing expert knowledge, and describes a representative example for the proposed workflow from remote sensing imagery to GIS. The strategies are demonstrated using the first object-oriented image analysis software on the market, e-Cognition, which provides an appropriate link between remote sensing imagery and GIS. The study in [63], demonstrates that the integration of satellite remote sensing and GIS was an effective approach for analyzing the direction, rate, and spatial pattern of land-use change. The further integration of these two technologies with Markov modeling was found to be beneficial in describing and analyzing land-use change processes. These wireless devices have sensors to collect data from the surrounding environment and pass the data onto some main location. Each wireless device also has a transmitter and receiver, which are used to communicate with other wireless devices or gateway within a network. The gateway, also known as middleware, transfers the sensed data to the main location, which logs in the data, and the data is then available to view, process, and analyze via a user interface. The work in [64], reports an investigation into the application of the integration of remote sensing and geographic information systems (GIS) for detecting urban growth and assessing its impact on surface temperature in the region. Remote sensing techniques were used to carry out land use/cover change detection by using multi-temporal Landsat Thematic Mapper data. Urban growth patterns were analyzed by using a GIS-based modeling approach. The integration of remote sensing and GIS was further applied to examine the impact of urban growth on surface temperatures.

Geo-Sensor Framework
In this section, we present our proposed geo-sensor framework's design and implementation modules along with configurations. Figure 2 shows the conceptual diagram for the geo-sensor framework for the deployment of multiple platforms. The data collected from the sensor networks is first passed onto the sensor middleware, where the sensor network's mapping to a dedicated sensor platform is done. Then, the data is passed onto the sensor platform via sensor middleware. Each sensor network's spatial context is managed at a Geo platform. At the geo-sensor composite toolbox, the assistance for the DIY geo-sensor network's deployment is provided. Geo-sensor framework integrates the services provided by the geo-sensor composition toolbox and geo-sensor platform to enable the geo-sensor services provision and the network's visualization for the client end.
Appl. Sci. 2019, 9, x 5 of 22 context is managed at a Geo platform. At the geo-sensor composite toolbox, the assistance for the DIY geo-sensor network's deployment is provided. Geo-sensor framework integrates the services provided by the geo-sensor composition toolbox and geo-sensor platform to enable the geo-sensor services provision and the network's visualization for the client end.

Geo-Sensor Framework and Geo-Sensor Platform Generation
In this sub-section, we present the system design for our proposed geo-sensor framework and multiple geo-sensor platform generation.
In Figure 3, we present the detailed configurations diagram for the proposed geo-sensor framework module interactions for multiple platform deployment. A geo-sensor framework offers a main service of geo-sensor content service. The geo-sensor content service has logical implementation for sensors involved in the network and geographical context of the sensors provided by sensor content service and geo content service, respectively. The sensor content service offers a sensor information manager and sensor's middleware configuration manager. The geo-sensor framework has a virtual sensor platform at one end, from where the sensor network's information is passed to the framework. It creates the sensors networks' profiles using the geo-sensor composite toolbox, which is later also visualized to the client end for client-level updates. Each time a service is created at the geo-sensor framework, it has to be registered at the geo-sensor service registry to maintain each sensor network's detailed history log. The geo-sensor framework eventually deploys the multiple geo-sensor platforms for multiple networks by mapping each of the network's information to its respected platform using the geo and sensor content services, geo-sensor composite toolbox, and geo-sensor service registry.

Geo-Sensor Framework and Geo-Sensor Platform Generation
In this sub-section, we present the system design for our proposed geo-sensor framework and multiple geo-sensor platform generation.
In Figure 3, we present the detailed configurations diagram for the proposed geo-sensor framework module interactions for multiple platform deployment. A geo-sensor framework offers a main service of geo-sensor content service. The geo-sensor content service has logical implementation for sensors involved in the network and geographical context of the sensors provided by sensor content service and geo content service, respectively. The sensor content service offers a sensor information manager and sensor's middleware configuration manager. The geo-sensor framework has a virtual sensor platform at one end, from where the sensor network's information is passed to the framework. It creates the sensors networks' profiles using the geo-sensor composite toolbox, which is later also visualized to the client end for client-level updates. Each time a service is created at the geo-sensor framework, it has to be registered at the geo-sensor service registry to maintain each sensor network's detailed history log. The geo-sensor framework eventually deploys the multiple geo-sensor platforms for multiple networks by mapping each of the network's information to its respected platform using the geo and sensor content services, geo-sensor composite toolbox, and geo-sensor service registry. Geo-sensor content service handles the deployment logic for the spatial context of the sensors in the sensor network. It then maps the spatial contextual information at the geo platform module in and sensor information at the sensor platform in order to generate an integrated geo-sensor platform for the given sensor network. The mapped information at the geo-sensor platform is processed at the geo-sensor composite toolbox for maintaining the spatial context-based sensor profile for the sensor networks. Once the spatial context-based profiles are completed, the information mapped onto the geo-sensor platform is ready for the client visualization client services' provision. The geo-sensor provider service at the geo-sensor platform handles the GIS service provision deployed at the geo platform sub-module and sensor service provision deployed at the sensor platform sub-module. The integrated logic of both the sub-modules enables the geo-sensor profile visualization and service provision to the client; for the spatial context-based sensor networks' profile queries ( Figure 4). Geo-sensor content service handles the deployment logic for the spatial context of the sensors in the sensor network. It then maps the spatial contextual information at the geo platform module in and sensor information at the sensor platform in order to generate an integrated geo-sensor platform for the given sensor network. The mapped information at the geo-sensor platform is processed at the geo-sensor composite toolbox for maintaining the spatial context-based sensor profile for the sensor networks. Once the spatial context-based profiles are completed, the information mapped onto the geo-sensor platform is ready for the client visualization client services' provision. The geo-sensor provider service at the geo-sensor platform handles the GIS service provision deployed at the geo platform sub-module and sensor service provision deployed at the sensor platform sub-module. The integrated logic of both the sub-modules enables the geo-sensor profile visualization and service provision to the client; for the spatial context-based sensor networks' profile queries (Figure 4).  Firstly, the sensor network addition request is made by the client. Once the sensor addition request is made, the middleware allocation to the sensors involved in the network is done. The physical sensors ID mappings are done to the virtually generated IPs. Next, the spatial context profile for each sensor involved in the network is created. The spatial context-based profiles include the sensor model and type information as well as the sensor's geographical information. After creating the profiles, the content services are registered at the service registry, and, finally, the geo-sensor platform for the added sensor network is deployed, along with the services provision, at the client view. Figure 6 shows the sequence diagram for geo-sensor service provision based geo-content service, sensor content service, geo provision service, and content provision service. The sensor data is passed onto the content service via sensor middleware. First, the middleware configurations are performed, and then sensor readings, after a certain interval, are sent to the sensor platform. The client query regarding sensor network is passed onto the sensor provision service under a geo-sensor platform, and the client query regarding the spatial context of the sensor is passed onto the geo provision service in the geo-sensor platform. The edit queries from the client are passed onto the content service, which interacts with the geo-sensor toolbox and performs the edit operations and sends a response back.

Geo-Sensor Composite Toolbox
In this sub-section, we present the geo-sensor composite toolbox module of the proposed system.
The geo-sensor composite toolbox has a vital role in the overall system. It provides the basic functionalities, which enable the client to add a sensor network along with its' geo-spatial context and also manages the network remotely. It has three functioning sub-modules as geo-sensor information manager, middleware information manager, and service information publishing  Once the sensor addition request is made, the middleware allocation to the sensors involved in the network is done. The physical sensors ID mappings are done to the virtually generated IPs. Next, the spatial context profile for each sensor involved in the network is created. The spatial context-based profiles include the sensor model and type information as well as the sensor's geographical information. After creating the profiles, the content services are registered at the service registry, and, finally, the geo-sensor platform for the added sensor network is deployed, along with the services provision, at the client view. Figure 6 shows the sequence diagram for geo-sensor service provision based geo-content service, sensor content service, geo provision service, and content provision service. The sensor data is passed onto the content service via sensor middleware. First, the middleware configurations are performed, and then sensor readings, after a certain interval, are sent to the sensor platform. The client query regarding sensor network is passed onto the sensor provision service under a geo-sensor platform, and the client query regarding the spatial context of the sensor is passed onto the geo provision service in the geo-sensor platform. The edit queries from the client are passed onto the content service, which interacts with the geo-sensor toolbox and performs the edit operations and sends a response back.

Geo-Sensor Composite Toolbox
In this sub-section, we present the geo-sensor composite toolbox module of the proposed system. The geo-sensor composite toolbox has a vital role in the overall system. It provides the basic functionalities, which enable the client to add a sensor network along with its' geo-spatial context and also manages the network remotely. It has three functioning sub-modules as geo-sensor information manager, middleware information manager, and service information publishing (Figure 7).
The geo-sensor information manager generates the spatial contextual based sensor profile for the sensor network and creates the geo-sensor profile handler for the content services access in the geo-sensor framework. The middleware manager generates the middleware mapping information for each sensor platform and creates the access handler for the geo-sensor framework. Service information publishing generates the service scripts for each added sensor network.
A geo-sensor profile is composed of building information, floor information, and room information with marks on a map image representing the geographical location of the physically installed sensors. It also contains the physical sensor mappings for the virtual platforms and detailed sensor information. The geo-sensor profile provides the geo-sensor query functionalities as add geo-sensor network data, access geo-sensor network data, update geo-sensor network data, or delete geo-sensor network data.
Appl. Sci. 2019, 9, x 8 of 22 ( Figure 7). The geo-sensor information manager generates the spatial contextual based sensor profile for the sensor network and creates the geo-sensor profile handler for the content services access in the geo-sensor framework. The middleware manager generates the middleware mapping information for each sensor platform and creates the access handler for the geo-sensor framework. Service information publishing generates the service scripts for each added sensor network. A geo-sensor profile is composed of building information, floor information, and room information with marks on a map image representing the geographical location of the physically installed sensors. It also contains the physical sensor mappings for the virtual platforms and detailed sensor information. The geo-sensor profile provides the geo-sensor query functionalities as add geo-sensor network data, access geo-sensor network data, update geo-sensor network data, or delete geo-sensor network data.       Figure 8 shows the sensor database entity relationship diagram. In the sensor database, we have sensor information, sensor type information, sensing data, sensing list, sensing category, and middleware information. Sensor_Information   Figure 9 shows the geo database entity relationship diagram. In the geo database, we have map information, map percent information, map data, building information, building mark, floor information, floor percent, room information, and room mark. Map_Informaiton   Figure 9 shows the geo database entity relationship diagram. In the geo database, we have map information, map percent information, map data, building information, building mark, floor information, floor percent, room information, and room mark. Map_Informaiton

Implementation
In this section, we implement the proposed architecture for the geo-sensor framework and multi-platform deployment. The sub-sections below illustrate the implementation environment, APIs (Application Program Interface) developed for the platforms, system implementation output, and benchmarking environment.

Implementation Environment
The implementation environment is shown below in Table 1. We have implemented RESTful based web-services on the windows net framework and web-based application client.

Implemented System Output
In this sub-section, we present the implementation results of our proposed geo-sensor framework and platform deployment based on the geo-sensor composite toolbox.
In Figure 10a, the execution screen for the sensor platform's sub-module is presented, while in Figure 10b, the execution screen for the geo platform's sub-module is presented. In Figure 10c, the geo-sensor framework's deployed available geo-sensor platforms' list is given. Figure 10d shows the

Implementation
In this section, we implement the proposed architecture for the geo-sensor framework and multi-platform deployment. The sub-sections below illustrate the implementation environment, APIs (Application Program Interface) developed for the platforms, system implementation output, and benchmarking environment.

Implementation Environment
The implementation environment is shown below in Table 1. We have implemented RESTful based web-services on the windows net framework and web-based application client.

Implemented System Output
In this sub-section, we present the implementation results of our proposed geo-sensor framework and platform deployment based on the geo-sensor composite toolbox.
In Figure 10a, the execution screen for the sensor platform's sub-module is presented, while in Figure 10b, the execution screen for the geo platform's sub-module is presented. In Figure 10c, the geo-sensor framework's deployed available geo-sensor platforms' list is given. Figure 10d shows the geo-sensor platform screen after the selection of the "computer department platform" in Figure 10c. The geo-sensor platform screen shown in Figure 10d has a full map view of the Jeju National University with a selected department highlighted to navigate through its floor for accessing to geo-sensor provision services. geo-sensor platform screen after the selection of the "computer department platform" in Figure 10c. The geo-sensor platform screen shown in Figure 10d has a full map view of the Jeju National University with a selected department highlighted to navigate through its floor for accessing to geo-sensor provision services. Once a geo-sensor platform is selected, as shown in Figure 10c, the client can either view its geographical based sensor details or head to the composition toolbox. Figure 11 shows the spatial context-based visualization of installed sensors at the selected geographical location. Once the client selects onto a specific sensor placed at a specific location onto the map, the client can view detailed sensor information, such as sensor name, sensor key, sensor location, sensor work state, and the sensor's current readings. Once a geo-sensor platform is selected, as shown in Figure 10c, the client can either view its geographical based sensor details or head to the composition toolbox. Figure 11 shows the spatial context-based visualization of installed sensors at the selected geographical location. Once the client selects onto a specific sensor placed at a specific location onto the map, the client can view detailed sensor information, such as sensor name, sensor key, sensor location, sensor work state, and the sensor's current readings.  Figure 12 shows the geo-sensor composite toolbox execution screen for building information management ( Figure 12a) and floor information management (Figure 12b). The composition toolbox enables services for making changes, such as the addition of new sensors network, deletion of sensor or map data, or updating of sensor or map data. Figure 12a shows the building information management screen where the client can get overall building information, such as building map information or the building's floor information. In order to navigate to a particular floor, the client would select the floor number from the building map, as shown in the highlighted region A in Figure 12a. After selecting the floor number, the client would navigate to the floor information management, as shown in Figure 12b. Within floor information management is detailed room-wise floor information along with available sensors in each room. Upon clicking a room, the client would get the option to bind a sensor onto the selected location. On clicking the binding sensor option, the client would navigate to the execution screen shown in Figure 12c. The client can bind a new sensor at the selected spot or delete/update an existing one.
(a) (b) Figure 11. Geo-sensor visualization for Internet of Things (IoT) environments. Figure 12 shows the geo-sensor composite toolbox execution screen for building information management ( Figure 12a) and floor information management (Figure 12b). The composition toolbox enables services for making changes, such as the addition of new sensors network, deletion of sensor or map data, or updating of sensor or map data. Figure 12a shows the building information management screen where the client can get overall building information, such as building map information or the building's floor information. In order to navigate to a particular floor, the client would select the floor number from the building map, as shown in the highlighted region A in Figure 12a. After selecting the floor number, the client would navigate to the floor information management, as shown in Figure 12b. Within floor information management is detailed room-wise floor information along with available sensors in each room. Upon clicking a room, the client would get the option to bind a sensor onto the selected location. On clicking the binding sensor option, the client would navigate to the execution screen shown in Figure 12c. The client can bind a new sensor at the selected spot or delete/update an existing one.  Figure 12 shows the geo-sensor composite toolbox execution screen for building information management ( Figure 12a) and floor information management (Figure 12b). The composition toolbox enables services for making changes, such as the addition of new sensors network, deletion of sensor or map data, or updating of sensor or map data. Figure 12a shows the building information management screen where the client can get overall building information, such as building map information or the building's floor information. In order to navigate to a particular floor, the client would select the floor number from the building map, as shown in the highlighted region A in Figure 12a. After selecting the floor number, the client would navigate to the floor information management, as shown in Figure 12b. Within floor information management is detailed room-wise floor information along with available sensors in each room. Upon clicking a room, the client would get the option to bind a sensor onto the selected location. On clicking the binding sensor option, the client would navigate to the execution screen shown in Figure 12c. The client can bind a new sensor at the selected spot or delete/update an existing one.

Analysis Results
In this section, we present the performance analysis and comparisons for our proposed geo-sensor framework for IoT environments. In Section 5.1, we present the analysis for the geo-sensor framework and geo-sensor toolbox performance in terms of response times, upload execution times for virtual objects (VOs) of the sensor, and geo-sensor services access response time.
We have implemented the proposed system based on both SOAP and RESTful web services, and in Section 5.2, we present the comparisons among the RESTful and SOAP web-services based implementations.

Geo-Sensor Framework Performance
In Figure 13, we evaluate the connection request response time from the geo-sensor framework for selected geo-sensor service visualization. The service visualization will load the geo-sensor network with a loading site map along with the sensors list, details, and available controls. In order to test the geo-sensor service access and visualization response time, multiple access attempts are made to the service. It takes around 231.74 ms to access the service visualization, which seems to be a reasonable amount of time for the proposed scenario.
However, the tested services are for loading the mini-map visualization, sensors involved along with the details of each sensor, sensor images if available, and sensors' states. For viewing the total map, a separate request is made further.

Analysis Results
In this section, we present the performance analysis and comparisons for our proposed geo-sensor framework for IoT environments. In Section 5.1, we present the analysis for the geo-sensor framework and geo-sensor toolbox performance in terms of response times, upload execution times for virtual objects (VOs) of the sensor, and geo-sensor services access response time.
We have implemented the proposed system based on both SOAP and RESTful web services, and in Section 5.2, we present the comparisons among the RESTful and SOAP web-services based implementations.

Geo-Sensor Framework Performance
In Figure 13, we evaluate the connection request response time from the geo-sensor framework for selected geo-sensor service visualization. The service visualization will load the geo-sensor network with a loading site map along with the sensors list, details, and available controls. In order to test the geo-sensor service access and visualization response time, multiple access attempts are made to the service. It takes around 231.74 ms to access the service visualization, which seems to be a reasonable amount of time for the proposed scenario. In Figure 14, we compare the execution time results for the total map size loading process in comparison to the mini-map size loading process.  However, the tested services are for loading the mini-map visualization, sensors involved along with the details of each sensor, sensor images if available, and sensors' states. For viewing the total map, a separate request is made further.
In Figure 14, we compare the execution time results for the total map size loading process in comparison to the mini-map size loading process. In Figure 14, we compare the execution time results for the total map size loading process in comparison to the mini-map size loading process. Now, we test the response time for multiple services access by multiple users at the same time to evaluate the system performance under-load scenario. Figure 15 presents the comparison of the connection request response time made from multiple users to access multiple services at the same time. The service access and visualization have to be loaded for multiple requests simultaneously in this scenario. We have evaluated multiple geo-sensor service access with a varying number of requests and varying number of active services. In the graph below, we can clearly observe that as the load of access requests and active sessions increases, the delay in responses the system witnesses, and, hence, the response time also increases. In our performed evaluation scenarios, the maximum execution time under 51 requests and 10 active users turn out to be around 3880.63 ms, and the average response time for the system under varying load scenarios turn out to be 1558.16 ms. Hence, the system response time under the worst load scenarios have delays up to a maximum of around a little less than 4 s, and on average, with varying load scenarios, remains around 1.5 s. We can safely say that the overall system performance under varying loads is tolerable, considering system service load requirements.  4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27  Now, we test the response time for multiple services access by multiple users at the same time to evaluate the system performance under-load scenario. Figure 15 presents the comparison of the connection request response time made from multiple users to access multiple services at the same time. The service access and visualization have to be loaded for multiple requests simultaneously in this scenario. We have evaluated multiple geo-sensor service access with a varying number of requests and varying number of active services. In the graph below, we can clearly observe that as the load of access requests and active sessions increases, the delay in responses the system witnesses, and, hence, the response time also increases. In our performed evaluation scenarios, the maximum execution time under 51 requests and 10 active users turn out to be around 3880.63 ms, and the average response time for the system under varying load scenarios turn out to be 1558.16 ms. Hence, the system response time under the worst load scenarios have delays up to a maximum of around a little less than 4 s, and on average, with varying load scenarios, remains around 1.5 s. We can safely say that the overall system performance under varying loads is tolerable, considering system service load requirements.

Performance Comparisons for RESTful and SOAP Based Web Services Implementation
In this sub-section, we evaluate the performance of system operations executed based on RESTful web services in comparison to the execution based on SOAP web services.
In Figure 16, we present the comparison results for geo context-based sensor binding process between RESTful and SOAP implementations. It shows the time taken in order to bind a sensor object onto a geographical location in the specific position of the given map. We can observe a clear

Performance Comparisons for RESTful and SOAP Based Web Services Implementation
In this sub-section, we evaluate the performance of system operations executed based on RESTful web services in comparison to the execution based on SOAP web services.
In Figure 16, we present the comparison results for geo context-based sensor binding process between RESTful and SOAP implementations. It shows the time taken in order to bind a sensor object onto a geographical location in the specific position of the given map. We can observe a clear difference and decrease in the execution time taken by the RESTful based services as compared to SOAP, which proves the RESTful based implementation to be better in the given scenario.

Performance Comparisons for RESTful and SOAP Based Web Services Implementation
In this sub-section, we evaluate the performance of system operations executed based on RESTful web services in comparison to the execution based on SOAP web services.
In Figure 16, we present the comparison results for geo context-based sensor binding process between RESTful and SOAP implementations. It shows the time taken in order to bind a sensor object onto a geographical location in the specific position of the given map. We can observe a clear difference and decrease in the execution time taken by the RESTful based services as compared to SOAP, which proves the RESTful based implementation to be better in the given scenario. In Figure 17, we present the map navigation query's response time comparisons based on pixel movement between the REST and SOAP implementations of the proposed framework. Each time the client navigates the map view, new blocks of maps are loaded depending on the move. It shows the comparison of the experiment results for loading the map move data from the geo sub-module and sensor data onto the moved location from the sensor sub-module. The data from the geo sub-module and the sensor sub-module are loaded via the geo-sensor platform and deployed by the geo-sensor framework. Every time, both the protocols, SOAP and REST, are tested with the same interval of move operation as a move of 100 pixels, 150 pixels, 200 pixels, 250 pixels, 300 pixels, 350 pixels, and 400 pixels. The results in response to each move operation for both the web services implementations are recorded in terms of the response time by the geo-sensor platform. The results clearly show that REST based web services outperform the SOAP based web services. comparison of the experiment results for loading the map move data from the geo sub-module and sensor data onto the moved location from the sensor sub-module. The data from the geo sub-module and the sensor sub-module are loaded via the geo-sensor platform and deployed by the geo-sensor framework. Every time, both the protocols, SOAP and REST, are tested with the same interval of move operation as a move of 100 pixels, 150 pixels, 200 pixels, 250 pixels, 300 pixels, 350 pixels, and 400 pixels. The results in response to each move operation for both the web services implementations are recorded in terms of the response time by the geo-sensor platform. The results clearly show that REST based web services outperform the SOAP based web services. In this sub-section, we can conclude that REST is better in performance in comparison to SOAP for our application. The REST web services perform better through caching the information, and REST also allows the use of JSON, which provides faster data parsing. With JSON, REST offers better service to the browser uses. Also, our proposed framework is web-based and uses JSON. Table 2 provides a comparison between REST and SOAP web services.   In this sub-section, we can conclude that REST is better in performance in comparison to SOAP for our application. The REST web services perform better through caching the information, and REST also allows the use of JSON, which provides faster data parsing. With JSON, REST offers better service to the browser uses. Also, our proposed framework is web-based and uses JSON. Table 2 provides a comparison between REST and SOAP web services.

Discussion and Conclusions
In this work, we first study the geo-sensor networks and geo-sensor services and present a user flexible DIY geo-sensor framework, which can be used for virtually uploading the geo-sensor networks' objects and services in the cyber world. The proposed work first focuses on the design of a geo-sensor framework based on multiple sensor platforms and geo platforms instances for the deployment of multiple geo-sensor services to the geo-sensor framework. Every time a user wishes to upload a geo-sensor network to the geo-sensor framework, the user gets dedicated instances of the sensor platform and geo platform for uploading of the geo-sensor network and geo-sensor services. Once uploaded, the authorized users can access the available geo-sensor services via the geo-sensor platform. The proposed framework provides real-time context data management using the geo-sensor composite toolbox. Using such a setup, it is possible to easily add other systems providing sensor nodes and map the information to the geo-sensor platform in order to make the geo-sensor networks easily accessible and manageable.
Many works and projects have been done in geo-sensing, mainly focusing on the goal of collecting real-time spatial and environmental data. Most of these studies relied on volunteers for the data collection process [65,66]. The people-centric sensing involved the data collection done by people carrying mobile sensors to various locations [67]. Many of the proposed approaches were one way or the other, solely for the benefit of specific entities, companies, or organizations trying to carry out research of data collection for their specific purposes. Zhang et al. [11] pointed out this fact and started a DIY project (CUSS) with an aim to involve people in not only the data collection process but also in the decision-making process based on the collected data. The project CUSS is in its initial stages and has limitations in its definitions and applications. The users in CUSS are also not provided with the facilities of creating their own geo-sensor services and managing them via a geo-sensing composite toolbox, instead, the CUSS is currently more focused on data collection by DIY VOs created by users. It provides a sensing visualization for a smart city's overall environmental picture and smart city decisions. Whereas, we provide a framework that users can use to create their own scenario-based virtual geo-sensor networks by binding the objects as VOs and service creation. Table 3 shows the comparisons of our deployed framework and CUSS. Further, in this work, we have implemented the geo-sensor services based on the RESTful protocol and SOAP protocol and drawn comparisons among both the web services performance in terms of various operation response times. In Table 4, we present the average performance result comparisons between the REST web services and SOAP web services, and we also take out the average difference between the performances of both services in terms of execution time for various geo-sensor operations evaluated above, such as sensor binding, map navigation, map viewer, and map management. Map management includes the operations of map loading, building map actions, floor map actions, map zoom in, and map zoom out. We can clearly observe from the results that the RESTful web services are better suited and efficient for the deployment of such frameworks with multiple platforms.

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