Keywords

1 Introduction

Tourism is an important economic activity for many countries in the world. For example, more than 1.3 million tourists visited Namibia in 2015 [1]. One of the country’s most important attractions is the Etosha National Park. Etosha National Park is a 22.270 km2 large wildlife sanctuary located in the north of Namibia, Southern Africa [2] and is home to 114 different mammals, which can be observed in their natural habitat [3]. Visitors can either explore the park on their own, if they bring a car with off-road capabilities, or can partake in a guided tour with a driver from the Etosha National Park staff.

Getting to see a specific animal requires a lot of luck in such a vast, open space, which is why every lodge inside the park has their own collective book of animal sightings, where visitors can inscribe their most interesting animal sightings with their location, date and time or browse through previous sightings made by other visitors.

Unfortunately, those books’ information is often outdated since sightings are mostly inscribed long after the sighting was made. Additionally, the different books in the different lodges contain different information, since visitors only report their sightings in one of the lodges as opposed to all of them. This makes it difficult to search for specific sightings and also aggravates the creation of informative statistics.

The idea was thus to create an animal tracking application giving a user the possibility to use their smartphone in order to upload a sighting with its corresponding geolocation data to a server and to quickly access other people’s sightings.

Animal tracking has been done for far longer than technology is around. Since the beginnings of mankind, animal tracking was used when hunting for food. When looking at African countries and especially Namibia, there are still tribes that to this day have remarkable skills when it comes to animal tracking.

One of those is the native Namibian tribe of the San [4] who have expert knowledge when looking for ‘spoors’, a term used to describe animal tracks. Experienced trackers can utilise ‘ground spoor, vegetation spoor, scent, feeding signs, urine, faeces, saliva, pellets, territorial signs, paths and shelters, vocal and other auditory signs, visual signs, incidental signs, circumstantial signs and skeletal signs’ [5] in order to track down animals. During a study with four San hunters, they demonstrated their incredible knowledge and were able to correctly identify the animal species from a spoor in 147 cases [6]. In most of the cases, they were also able to identify the sex, age and if the animals were individuals.

The San traditionally use bow and arrow when hunting for animals. First, they have to try to find animals spoors, track down the animal, shoot it with a poisonous arrow and then follow the animal until the poison takes effect.

However, acquiring such a complex skill takes many years of learning and immense knowledge of the animals and nature. While expert hunters may recognise spoors immediately, unknowing tourists might completely overlook them [5].

In National Parks like Etosha, tourists have the possibility to book tours with expert guides who are still able to interpret spoors in order to find animals. But many tourists also use the opportunity to discover the park on their own in their private cars and could greatly benefit from an application that uses crowdsourcing in order to record and share sightings of interesting animals.

Even the approach of leaving information for others is not a modern concept, the nomadic Penans in Malaysian Borneo use Oroo’, an incredibly complex forest sign language, in order to leave messages for others [7]. The Penans use combinations of twigs and leaves in order construct messages, leave them in the forest and other Penans coming upon them know how to interpret the messages.

The goal of our project is similar: to enable people to use their smartphone to record animal sightings and give them the possibility to make this information available to other visitors coming after them.

2 State of the Art

Digital animal tracking and habitat monitoring have been explored during many studies. Many of them make use of wireless sensor networks (WSN). Two approaches have proven to be successful in the past:

  • Tracking devices (often in the form of collars) attached to animals (or other mobile entities for that matter), that periodically send data to a base station;

  • Radio frequency identification (RFID) tags attached to animals and RFID readers setup in strategic locations. Every time an animal with an RFID tag passes the reader, data is received and recorded.

The tracking device approach has been effectively used with zebras [8] and deer [9], while the RFID solution provided good result in tests with ducks [10] and badgers [11].

However, this wireless sensor network approach was not feasible for our project in Etosha National Park. The above-mentioned approaches do well in, for example, scientific studies, with a smaller number of animals (<100) needing to be tracked. While this could be used to track a specific species or group of animals—maybe endangered ones in order to ensure their well-being—it could not be used to track all of the animals tourists might be interested in.

Because of that, the decision was made to use a crowdsourcing approach, as was basically used before with the sighting books at the lodges. This analogue version should be improved using modern technology. Instead of using books to log sightings, the sightings should be recorded with a smartphone and then shared with other users via Internet.

Big advantages of this strategy are that no hardware needs to be deployed in the park, which might distress animals and would probably not be permitted by the park authorities anyway, and that a smartphone can be used as the recording device. This means that no additional hardware needs to be handed out to visitors, as nowadays most people always have their own device with them.

The idea for a crowdsourcing animal sightings app is not completely new. A similar application already exists for African animals named ‘Africa: Live’ [12]. This application shows a map (Fig. 1, left image), onto which users can tap in order to add sightings. The user is taken to a new view where details of the sighting (which species, their activity, etc.) can be entered (Fig. 1, middle image). The application also features an offline mode, which is, however, hidden behind a paywall (Fig. 1, right image). The coordinates of a sighting are determined by where the user taps on the map. Unfortunately, this is a very inaccurate way to determine the location of a sighting. A better approach would be to use GPS coordinates for the localisation.

Fig. 1
figure 1

Multiple screenshots of the ‘Africa: Live’ application

Full size image

The ‘Africa: Live’ application features a wide variety of species as well as the option to report suspicious activities (such as poaching). The collection of sightings of some endangered species is allowed, but they will not show on the map publicly.

This application works well for African animals but does not allow the creation of sightings from other regions of the world. It would, therefore, be interesting to create an application that could be easily adapted to allow sightings of animal species from all over the world.

3 Requirements and Limitations

Before the start of the project, it was planned to create a client-server application with three different types of clients. The first two were meant to be native mobile applications, the third a webpage. At the very start, the general requirements and limitations had to be discussed and the project goals adjusted accordingly.

3.1 Internet Connection

One big limitation arose during the development: the poor network coverage in national parks such as the Etosha National Park. There are signal masts placed at the gates and lodges but they are not enough to cover the entire park. Internet access is available within a radius of 10–15 km of the lodges and gates but elsewhere smartphones mostly lack reception.

Figure 2 depicts the mobile network coverage in Namibia provided by MTC (Fig. 2, left side) and Telecom Namibia (Fig. 2, right side). Etosha National Park (outlined in blue) is not covered completely by the providers.

Fig. 2
figure 2

Mobile network coverage of the two main mobile network providers in Namibia (Etosha National Park is outlined in blue) [13]

Full size image

There are five lodges and four gates in Etosha National Park that each has their own signal mast providing network coverage. Since Etosha is roughly 22.275 km2 in size and the masts only cover between 2.200 and 4.900 km2 (using 10 and 15 km for the radius of the masts’ reach), this leaves 78–90% of Etosha without network coverage.

This meant that the application needed an offline mode that stores the sighting data in a local database on the smartphone during times when the phone has no network access.

The network problem finalised the decision to only implement native mobile applications rather than a webpage. With Android and iOS running on over 90% of mobiles and tablets [14], it was decided to develop the application for those two operating systems.

At the beginning of the project, it was planned to take a photo of a sighting and store it on the server together with the sighting’s location, timestamp and other information. However, because of the limited network access, this idea was dismissed. Uploading and downloading the image would take too much time. According to nurdology.com [15], uploading even a 320 × 240 pixel image would take 16 s using EDGE. Downloading the same picture from the server would only need 5.3 s; however, if there were multiple new sightings on the server waiting to be downloaded, this would take too long to download, especially if errors arise when connectivity and download progress are lost. It was therefore decided to not store images but only the name and a description of the activity of an animal, as well as GPS coordinates and a timestamp for the sighting. Opposed to the 225 kb of a 320 × 240 pixel image, the name, description, coordinates and timestamp of a sighting would only be 120 Bytes (for the JSON object see Sect. 4.3).

3.2 Legal Restrictions

When collecting animal sightings, it is important to keep legal restrictions in mind. Especially, important is to prohibit the collection of data of endangered species. Collecting their data and making the data available to the public would make it easier for poachers to find and harm those animals.

The application must therefore not include endangered species in order to protect them. In the region of Etosha National Park, this includes elephants and rhinos according to the Convention on International Trade in Endangered Species of Wild Fauna and Flora [16].

It would be a possibility to allow sightings of endangered species without distributing them to other users. This would mean that statistics of the data on the server could include those endangered species without having to fear poachers, since the data could never be requested from the server. However, to ensure the safety of the data on the server it would have to be encrypted.

4 Architecture

4.1 General Overview

The architecture of the application consists of multiple components. Figure 3 shows an overview of the architecture.

Fig. 3
figure 3

The basic client-server architecture of the application

Full size image

Sightings can be created using an Android or iOS client. The smartphone determines the current GPS location, the time and date and the user adds additional information about the sighting, e.g. which animal was seen and what the animal was doing at the time. The sighting data is then stored in the local SQLite database on the phone. Table 1 shows two sample sightings.

Table 1 Sample sightings
Full size table

If the phone has access to the Internet, it can communicate with the server. The server’s database and the local phone database are synchronised; new sightings made by the user are sent to the server and other users’ sightings are received from the server.

Sighting data is stored in a MySQL database on the server.

4.2 Offline Mode

An important feature of the application is the possibility to use it offline, when no network access is given at a location. In order to achieve this, the application checks for connectivity as soon as the application is started. If the application has access to the Internet, the local SQLite and remote server databases are synchronised.

If a sighting is added in offline mode—without a connection—then it is saved in the local database. The SQLite database has, amongst others for all the animal types and descriptions, two tables containing sightings: One with all the sightings from the server and one, where only the sightings made offline and awaiting upload are stored (Fig. 4).

Fig. 4
figure 4

The local SQLite database tables

Full size image

Whenever the main screen is accessed, the app tries to synchronise with the server. If the phone has access to the Internet, the not yet uploaded sightings are sent to the server and deleted from the upload queue. Afterwards, a request to the server is sent, and if other users have added new sightings since the last synchronisation, those are downloaded and added to the local database.

One issue that needs to be addressed in case of publication in an app store is if different users should be able to upload the same sighting. Due to the vast space of the Etosha National Park, single spots are not usually crowded with many tourists, but it could occur that multiple visitors spot the same animal and try to upload a sighting of it. It would of course verify the sighting, but would also crowd the database unnecessarily. It would therefore be mandatory to detect multiple sightings at the same time from the same area and add only one of them to the database.

4.3 JSON Data Format

For the communication between the client and server, the JavaScript Object Notation (JSON) was used. The following lines show an example of a sighting in JSON format.

Example of a Sighting in JSON format

Sightings have an ID, a keyword describing the animal, a description of what the animal was doing (sleeping, hunting, running, etc.) as well as a latitude, longitude and timestamp. Name and description are foreign keys pointing to entries in the name and description tables in the server database.

Timestamps in database are often generated on the server as opposed to on the client. However, in our application, this would result in saving the moment the data has been uploaded to the server rather than the moment the sighting has actually been made. Since the desired timestamp is the one of the sighting, the timestamp has to be created on the client and sent in the JSON object.

5 Implementation and Demonstration

The final implementation consists of two native mobile applications and a remote server. The Android client is written in Java and the iOS client was developed using Swift. The server uses nginx and offers a REST API written in PHP.

5.1 Client

Figure 5 shows screenshots of the finished Android client. Their functionality is going to be described in the following paragraphs.

Fig. 5
figure 5

Screenshots of the android application, main activity (left image), ‘Add a new sighting’ activity (middle image) and ‘Show sightings on map’ activity (right image)

Full size image
  1. A.

    Starting the app

The start screen of course shows the user all the possible functionalities of the app, in this case the four modes (Fig. 5, left image). The menu is accessible from every screen and contains a short tutorial for every screen, information about developers and licenses, a button to change the application’s language and a short notice about the exclusion of endangered species in the app.

On first access of the start screen, which marks the app start, the application checks for the required permissions (GPS and writing to external storage) and requests these from the user in case they are not given. The application also checks for network connectivity and syncs the SQLite database with the server database if it is reachable.

The local database is empty when the application is used for the first time after the installation and has to be filled with data from the server.

  1. B.

    Adding a sighting

One of the most important functionalities of the app is the creation of a new sighting (Fig. 5, middle image). The application retrieves the user’s current coordinates via a GPS manager; the user chooses an animal from a drop-down list as well as a short description of the animal’s current activity from another list (e.g. ‘Eating’, ‘Sleeping’ and ‘Herd 15+’).

Upon clicking ‘Save Sighting’, an empty sighting instance and a current timestamp are created. Afterwards, the application checks if the user selected an animal as well as a description. If this is not the case, then nothing further happens and a toast is triggered, making the user aware of the missing inputs. If both have been selected, then their values and the current latitude, longitude and timestamp are added to the empty sighting instance.

It was decided to record both the species and the activity of an animal in order to give a user more information in order to decide if he could still be able to see this animal. If a user just uploaded a sighting of a ‘Lion’ ‘running’, then another user arriving after the original poster will probably not get to see the animal. However, if a user posts ‘Giraffe’ ‘eating’ or ‘Zebra’ ‘sleeping’, then there is a higher chance to still get to see this animal for users arriving after the sighting was originally created.

The sighting is then added to the general local SQLite database, as well as an upload queue. This upload queue contains all the not yet uploaded sightings that will be sent to the remote server once connection is re-established.

The application then changes back to the main screen, where connectivity is checked. If Internet access is given, then the sightings in the queue are uploaded, and possible new sightings from other users downloaded from the server.

  1. C.

    Displaying the sightings on a map

This mode shows all of the sightings in the phone’s database on an Open Street Maps map [17]. It is also possible to search for specific animals and only display those on the map (Fig. 5, right image).

  1. D.

    Notifications of animal sightings

In order to receive alerts of new sightings of a specific animal species, a user can subscribe to an animal and get a push notification each time a new sighting of the subscribed animal is posted to the server (Fig. 6, left image). A subscription can be added by selecting a type of animal from the dropdown and then clicking ‘subscribe’. However, this is still a theoretical feature. While it is possible to add and display the subscriptions on this page, the actual push notifications and messages from the server have yet to be implemented.

Fig. 6
figure 6

Second set of screenshots of the android application, add subscription activity (left image), create report activity (middle image) and the menu item addressing endangered species (right image)

Full size image
  1. E.

    Creating a report

This shows an overview of all of the user’s own sightings and enables the user to trace their own route through the sightings’ GPS coordinates (Fig. 6, middle image). The overview shows all the animals seen in chronological order. On clicking on a list item, the GPS position and time the animal was seen at as well as the entered activity of the animal are being displayed.

Figure 6 (right image) shows the menu popup information for the endangered species.

Figure 7 shows the iOS client’s UI. This UI differs from the Android one as both applications used the native UI components of their operating systems, giving the Android application the typical Android look and the iOS one the typical iOS look, respectively.

Fig. 7
figure 7

Screenshots of the main screen (left image), show on map (middle image) and subscription feature (right image) of the iOS client

Full size image

5.2 Server

The server handles requests from the clients. Sighting data is being collected by the client and then sent to the server via an HTTP request in JSON format. The server API can be accessed via endpoints. Each endpoint is a uniform resource locator (URL), which is accessed with an HTTP verb. Valid HTTP verbs are, for example, POST, GET, PUT, PATCH and DELETE. The following endpoints are available:

  • GET/animals/Returns a list of available animals, e.g. lion.

  • GET/descriptions/Returns a list of available descriptions of animals, e.g. eating.

  • GET/sightings/Returns a list of sightings of the last 10 days.

  • POST/sightings/Accepts and saves a sighting.

The POST/sightings endpoint accepts a JSON object in the form of the JSON sighting example in Sect. 4.3.

The sightings are stored on the server in a MySQL database. This database currently has three important tables: animals—which lists all possible trackable animals, status—which lists all possible animal descriptions and sightings—which contains all the sightings ever sent to the server (see Fig. 4).

The server only returns the last 10 days worth of sightings whenever a client requests sightings. While older animal sightings from the last season or even year could possibly function as statistical data, they would only crowd the sightings map without being actually helpful for the task of finding animals.

Useful statistics might include where certain species are seen most often, if their movements follow specific patterns or if their behaviour differs from season to season, etc.

6 Field Tests of the Application

The implementation was tested during two game drives in Etosha National Park in Namibia. One of the test drives was done at the very beginning of the week before the implementation process had started and the second one at the end of the week in order to test the implementation.

The first game drive served multiple purposes. Most importantly, the students could actively experience and understand the use case of their future application. Additionally, the availability of mobile network access was documented throughout the drive. The results of this test undermined the importance to create an offline solution for the application (see Sect. 3.1).

Another task during this game drive was to collect valid sightings data that could function as test data in the database during the implementation phase of the project.

The process used to collect the test data was to take pictures of sightings and then extract GPS coordinates and the timestamp from the metadata of those images after the drive.

The second game drive was done after the implementation phase on the last day of the coding week. This drive was used to test the application that had so far been developed. After only few days of development not all of the features were fully implemented. However, the core features of creating a sighting, storing it in the local database and displaying them on the map were working.

Both times the drives started and ended at the eastern Von Lindequist Gate and had roughly the same route. It lead from the Von Lindequist Gate to Fort Namutoni and from there along the rim of the Etosha pan towards Halali and then back to the Von Lindequist Gate.

The following describes the results of the testing of the application’s previously described core features during the second game drive.

Sightings could be created with correct GPS location, timestamp, animal name and description, added to the local SQLite database and shown on the map.

While most of the sightings were collected correctly, two of the sightings were missing GPS coordinates. It appears that the respective smartphones were unable to retrieve test data at that moment. To prevent such faulty sightings from entering the database, a check for valid GPS data was implemented after this game drive.

Due to the short development time of only 4 days, the applications were only running locally on the Android and iOS test devices, but were not yet connected to a server. The connection to the server had to be implemented after the game drive.

Nevertheless, the server was tested in Berlin after the end of the coding week and no issues were experienced with getting animals, status or complete sightings and new sightings were correctly posted to the server database.

7 Result

The goal of the project was to create an application that would allow users to create and share animal sightings as well as retrieve other users’ sightings in the Etosha National Park. The project has been implemented for both Android and iOS devices and has been connected to a server and works both online and offline. All the components of our system have been tested and showed positive results. The application can be used with minimal setup—it is only necessary to instal the application on the smartphone—and without the distribution of additional hardware in the park, which might distress animals.

The project can therefore be seen as successful.

We had the possibility to discuss our application with the owner of a private game farm just outside Windhoek. While the reaction to the application was overall positive, he mentioned concerns about the possibility of poaching, if endangered species could be tracked with our application. He was pleased to hear that our application does not allow the tracking of those animals.

8 Future Work

The project resulted in a solid prototype of an animal tracking application that can be used both on and offline in the Etosha National Park. While this prototype provides a user with basic functionality, there exist multiple ideas in order to extend this prototype in the future.

For one, it would be possible to connect the application to an animal recognition tool. Instead of choosing the type of animal from a list, the user could take a photo of the animal and the correct type would be identified by the application itself. This could prevent faulty statistics due to wrong identification of an animal by the user.

While a tourist could of course distinguish a lion from a giraffe and add those sightings correctly, it might be more difficult to identify different species of antelopes. So while a user might not even want to add a false sighting, faulty sightings could still find their way into the database. Of course, crowdsourcing also gives users the possibility to intentionally add false sightings.

Image recognition could be a very good approach to solve this problem, while other mechanisms such as moderators cannot be used, as moderators would have to be at the site of a sighting at the same time as the user in order to be able to verify a sighting.

However, it might not be easy to implement image recognition in this context. Often, when seeing animals in the wild, it is only from afar. This means that one might not be able to get a clear picture of the animal, making animal recognition harder.

Additionally, the problem of limited network access would remerge. For the image recognition to work offline, information about all the detectable animals such as comparative images would have to be downloaded in advance and stored on the phone locally.

At the moment, the server only contains animal species specific to Namibia and the Etosha National Park. The different types of animals that can be used in the application are retrieved from the server and not hardcoded in the app. This means that the available types of animals could be easily adapted to the part of the world the user is currently in. Different packages of animals could be created for different regions of the world (e.g. animals such as lions, elephants, springboks, etc. for Namibia, bison, cougars, moose, etc. for Canada, kangaroos and koala bears, etc. for Australia and tigers, water buffalos, etc. for Asia). The server would then hand out the packages corresponding to the user’s GPS location.

Along with this, the application should also be internationalised. So far, the application features only two languages, English and German.

Another future task would be the implementation of the still theoretical feature of receiving push notifications for ‘subscribed’ animals, as mentioned in Sect. 5.1.

Finally, the overall users’ captured data could serve as an imperative input in animal studies and wildlife statistics on various topics such as animal movements in different seasons.

In case of publication of the application in an app store, it would also be necessary to enter a dialogue with the National Parks as to how they could benefit from such an app without having to fear that their rangers and guides might become obsolete. Those rangers of course can offer a lot of more in-depth knowledge to tourists than an application like Amtrack ever will. The application should therefore rather function as an addition to those rangers instead of exchanging them.