If you don't remember your password, you can reset it by entering your email address and clicking the Reset Password button. You will then receive an email that contains a secure link for resetting your password
If the address matches a valid account an email will be sent to __email__ with instructions for resetting your password
A novel crowdsensing platform to report the conditions of beaches.
•
A client application with a rich UI has been developed in Android.
•
Contributors can upload the state of a beach along with photos.
•
The back-end server allows to review all the reports submitted by contributors.
Abstract
Mobile Crowdsensing (MCS) has become an important solution to capture contextual data at large spatial scales. However, some relevant domains like the tourist sector suffer from a lack of mechanisms leveraging MCS to provide novel services. In this context, the present work introduces Beach and Weather (B&W) a novel participatory MCS tool where contributors are able to report the current state of the beach where they are currently located in. This way, we are able to provide a reliable and agile information system for beaches that would be instrumental in regions where the sun-and-beach tourism is a predominant economic activity.
In these days and age, personal mobile contrivances are equipped with a palette of multiple sensors. This allows to capture a large amount of contextual information related to the phone’s holders and their surrounding environment [
]. As an important side effect, this endless enrichment has eased the development of the Mobile CrowdSensing (MCS) paradigm which allows to perceive large-scale phenomena that cannot be detected at an individual level [
Most of the MCS systems proposed both in the industry and academic field focus on sensing tasks mainly related to urban or human-mobility settings like the detection of air pollution levels [
]. However, there is an important research and development gap in terms of MCS mechanisms able to perceive phenomena beyond the city field.
At the same time, there is a large number of Weather Information Systems (WISs) that report the current and future weather conditions of a particular spatial region (e.g. city) with great detail [
]. Some of these platforms have recently included, among their features, weather reports specially related to beaches. This way, they inform about relevant coastline ambient factors such as the expected water temperature, humidity level or wind speed in a particular beach.
Despite the fact that one of the worldwide most popular type of tourism is the one related to sun-and-beach activities (e.g. 60% of all European tourists prefer to vacation along the seaside) [
], the aforementioned WIS for beaches suffer from two important limitations. The first one is that they rely on data feeds that usually provide weather reports on a daily basis. However, beaches are specially sensitive locations whose weather conditions could change very fast in a few hours. Furthermore, they do not properly capture other contextual features of a beach location that might be also interesting for its potential users, such as the number of people in the location, the cleaning level of the sand or the water. These may be important factors that summer visitors may take into account in order go to one beach or another.
To address these shortcomings, we have implemented Beach & Weather (B&W), a participatory MCS service that provides an enhanced and timely WIS for beaches. By means of an Android application, users are able to report different aspects of a beach where they are currently located. Besides, it also allows to see the current state of other beaches according to the most recent users’ reports. Then, a back-end server, mainly developed in J2EE, collects and fuses all the generated information.
2. Software description
The general overview of B&W is shown in Fig. 1. As we can see, the system comprises two key elements, the client module, running as a mobile application, and the back-end server that collects and aggregates all the reports from the contributors. It also deals with the requests from the consumers who want to know the current state of a particular beach. The orchestration between the client and the server is done by means of a web service based on the Simple Object Access Protocol (SOAP). We will see the implementation details of these elements in the following sections.
Fig. 1General overview of the Beach & Weather platform. In the left side, each contributor reports the state of the beach where he is currently located as the blue arrows depict. In the right side, users or consumers of the platform can see the current state of the beaches based on the aggregated reports from all the contributors as the orange arrows show.
Fig. 2Workflow of the B&W mobile application. The Activities are depicted as blue boxes. Each blue arrow represents an Intent connecting 2 different views. Moreover, each activity is linked, by means of dashed orange arrows, with the Java class that gives it access to a particular service of the Back-end server.
The mobile application of B&W has been developed in Java and it is compatible with the Android API levels 23 to 28. More in detail, the source code of the application comprises 14 android.app. Activity classes. Fig. 2 shows their workflow and, as we can see, we have adopted the model-view-controller pattern to develop the mobile client. This way, each Activity (view) makes use of a third-party Java class (controller) to get access to the stored data in the back-end server (model). For the sake of clarity, we will describe the most important elements of this workflow based on the key steps described in Fig. 1.
Validation of users and contributors.
Once the mobile application is launched, the landing page is provided by the SplashScreenActivity. Then, the it automatically transitions to the TPMainActivityLogin activity. This activity relies on the Google sign-in mechanism to validate the registered users and contributors within the platform by means of their GMail credentials. This is handled by the UsuarioWSGoogleSignIn class of the mobile phone. This will generate a token that will be used by the user in future accesses. This type of token-based access is handled by the class UsuarioWSLogOnWithToken within the mobile application.
Send status report of a beach.
The main view of the application is provided by the TPMainMenuActivity class. From this view, we can move to the TPFormDataActivity that is in charge of delivering the status report of a beach to the back-end server. To do so, the aforementioned activity sends a JSON file to the back-end by calling the /addNewData method of the web service thought the DatosWSAddNew controller class. This JSON comprises, apart from a unique identifier of the target beach, 7 features describing the state of the beach according to the user. These features are defined by numerical values ranging from 1 to 10. In particular, they inform about the (1) wind speed, (2) swell level, (3) cloud coverage, (4) water cleanness, (5) sand cleanness, (6) occupancy level and (7) colored flag
In certain countries, like Spain, beaches usually include a warning flag among their premises to inform users about the sea weather conditions at each day by means of a 3-color code, read, yellow and green.
of the target beach. Furthermore, the TPFormDataActivity also allows the user to send a picture of the beach though the FotografiaWSAddNew controller class.
Find the closest beach of a contributor.
When a contributor wants to send a report, it can only be about the beach where he is currently located. To do so, TPFormDataActivity firstly discovers the closest beach of a user by sending his current GPS coordinates to the server thought the PlayasWSGetClosest controller. Next, the server returns back the beach whose spatial centroid is the closest to the user’s current coordinates by considering the Euclidean distance. It is important to remark that if a user is more than 600 meters away from his nearest beach, the system assumes that the user is not currently located in any beach and prevents him from deliver any report to the platform.
Search information of a beach.
The class in the mobile application to display the current state of a beach is StatusPlayaActivity. To do so, this activity uses the controller DatosWSGetStatusPlaya to retrieve a JSON file from the server comprising the 7 target features computed as the average values of all the received reports of the target beach in the present day. In order to display all the photos taken in that beach, a secondary activity, ListPhotosBeachActivity is used. This activity relies on the FotografíaWSGetPlaya controller to retrieve such photographs from the back-end module.
2.2 Back-end server
The back-end server provides a palette of methods to receive and send data from and to the mobile application. In that sense, Fig. 3 shows the different methods provided by such a server.
One of the key features of the back-end server is the estimation of the current state of a beach based on the received reports. The listing (given in page 5), extracted from the class TPHelperDatos.java of the backend server, shows the getBeachStatusAverage method in charge of computing such an estimation.
Last, the back-end server also includes a relational database to store the metadata of the monitored beaches along with the reports sent by contributors. As we can see in Fig. 4, the database is compound of 4 different tables, t_data comprises the timestamped and geo-located reports sent by contributors, t_photographs stores their photographs encoded in base64, t_beaches comprises the meta-data of the beaches currently supported by B&W and t_users defines all the users (contributors and consumers) registered in the platform.
Fig. 4Design of the relational database of the platform.
The present section provides an illustrative example of how B&W can be used to report the state of coastline beaches along with its look and feel in terms of visualization.
The login page of the mobile application is shown in Fig. 5a. As we can see, a user firstly needs to introduce valid GMail credentials to use the application. Then, the initial view of the mobile application of B&W displays the information related to the closest beach to the user’s current location. In that sense, Fig. 5b shows the general view of the mobile application reporting the current state of a beach based on the collected data. Fig. 5c shows the collaborative gallery of photos of the current beach. This gallery can be easily accessed by just clicking on the main photograph depicted in Fig. 5b.
Given the panel in Fig. 5b, the user can report the state of the beach where it is located by clicking on the button at the bottom part of the interface with the text in Spanish šCómo está la playa hoy? (How is the beach today?). In this case, the panel in Figs. 6a,b shows the different contextual factors of a beach that can be reported. Once the user clicks on the button !Y ahora envíalo! (And now, send it!) the JSON report is sent to the back-end server. The view of the application where a user can check all his submitted reports is shown in Fig. 6c.
Fig. 5Panels of B&W to show the state of a beach and search among the available beaches. The particular Activity in charge of each view is shown in brackets.
Due to its collaborative nature, the mobile application also allows users to register new beaches in the platform. As Fig. 7 shows, a contributor just needs to go the navigation view of the application (Fig. 7a), select the Añadir nueva playa (Add new beach) option (the one with the ＋ icon), complete the required meta-data of the new beach in terms of its (1) name, (2) UTM coordinates, (3) city, (4) postal code and (5) country along with an initial photograph (Fig. 7b). Last, users can also see all the registered beaches in the platform by means of a interactive map (Fig. 7c). By clicking in each red pin, we can get access to its current state (panel in Fig. 5b).
Fig. 6Panels of the mobile application related to the generation of reports. (a) and (b) View of B&W to report the state of a beach. This panel is split into two sub-figures for better visualization (TPFormDataActivity class). (c) List of reports submitted by the user thought his application (InfoSendedActivity class).
Fig. 8 shows 4 different panels of the back-end server. The first one is the landing page of the server with the login and password fields (Fig. 8a). The second one shows the panel listing all the beaches registered in the B&W platform (Fig. 8b). In this case, the administrators of the platform can manually verify the reliability of the information about the beaches reported by users. They can also modify certain meta-data of the beaches in case there is an error or remove duplicates. The third panel shows the gallery of photos of a particular beach collected by all the users (Fig. 8c). In this case, administrators can also remove certain photos provided they were somehow inappropriate or inaccurate by just clicking on the trash icon below each picture. Last, the fourth panel shows the list of all the registered users (clients and contributors) in the platform. In this case, the B&W administrators can enable, disable or even remove users from the platform.
Fig. 7Panels of B&W related to the management of beaches thought the mobile application. The particular Activity in charge of each view is shown in brackets.
With Android being one of the most widely used mobile phone operating systems worldwide, we foresee that B&W will be used by many users. Given the relevance of the sun-and-beach tourism in many different countries, we believe that this project constitutes a valuable boilerplate to deploy MCS-based solutions in such places.
In that sense, the current design of the platform, following the model-view-controller pattern, allows to easily adapt it to new settings. For instance, a slight modification of the user interface would allow to use the system to report the state of swimming lakes or, at a broader scale, other natural spaces with recreational facilities. More in detail, the proposed framework allows users to define new points of interest and inform about them. In the back-end part, the administrators are able to filter the reports from contributors
Another interesting impact of B&W is that it allows users to upload photographs of a particular place enriched with several weather-related meta-data. As a side effect, this would allow to eventually generate large datasets of labeled images of recreational spaces. Then, this collected data could be instrumental for the development of novel algorithms within the image-recognition field.
In operational terms, we evaluated the suitability of system from July to October, 2019 in Spain by releasing the mobile application in the Google Play Store. As a result, 32 unique contributors sent at least one report about 41 different beaches. In total, 980 reports and 550 photos were received by the platform.
Declaration of Competing Interest
The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.
Acknowledgments
Financial support for this research has been provided under grant PID2020-112827GB-I00, Spain
funded by MCIN/AEI/10.13039/501100011033.
References
Yan Z.
Chakraborty D.
Semantics in mobile sensing.
Synth. Lect. Semant. Web Theory Technol.2014; 4: 1-143
00009-X&id=gr1.jpg){kind=link}
00009-X&id=gr2.jpg){kind=link}
00009-X&id=gr3.jpg){kind=link}
00009-X&id=fx1001.jpg){kind=link}
00009-X&id=gr4.jpg){kind=link}
00009-X&id=gr5.jpg){kind=link}
00009-X&id=gr6.jpg){kind=link}
00009-X&id=gr7.jpg){kind=link}
00009-X&id=gr8.jpg){kind=link}