For my second project in University, I was placed in a group of 4. Our task was to use the location data from the app OwnTracks and create a web-based representation of the data, as well as creating an algorithm to track individual journeys made by users. The requirement for the project was that it was hosted on a virtual Ubuntu machine via Codio.

OwnTracks is an app that regularly reports data on the location of each user, such as longitude and latitude, altitude and the time of each report. This datastream can be subscribed to via an MQTT broker and subsequently stored in a database for later use.

I took an active leadership role in the project, and used the project management web app Asana to delegate tasks to the team.

Database Design

We began by designing the database that would store the location values, as well as creating an entity relationship diagram. There are three tables for data storage:

• The Locations table – stores the longitude and latitude of each MQTT report, alongside the date and time it was published
• The Journeys table – Stores all the journeys that have been undertaken by members of the group. Fields include Journey ID, User ID, start time and end time
• The Journey Waypoints – Stores each waypoint for all the journeys in the Journeys table, taking longitude, latitude, date and time, as well as the journey ID as a foreign key

The Location table is purely for the location data extracted from OwnTracks with no calculations or processing done on it. Journey and JourneyWaypoint are added to with calculations made from the original Location table data.

Data Collection

In order to build the database of locations, we were given some incomplete Python code for subscribing to the MQTT broker to retrieve the necessary information, to which we were guided to add filters for the usernames of our group.

The Python file then creates separate tables through an Oracle database, and populates the first Location table with the data parsed from the broker.

Calculating a Journey

As the group member with the most programming experience, I took on the task of developing the algorithm to determine when a user was on a journey, and how to assign each location as a waypoint of each journey.

The algorithm begins by first receiving an input of the OwnTracks position data from the MQTT server. From there it runs a number of conditional checks, including checking if the distance between this position and the last is great enough to conclude reasonable movement has occurred, and whether the speed they moved at is not unrealistic. If both these checks are true, then either a new journey is created for the user and the waypoint added if there is no existing journey, or the waypoint is added to the journey that the user is currently on.

Web Display

Since the project was running on Ubuntu, we had to host the server through the Jinja2 templating engine. This allowed us to run the web server and load HTML, CSS and resource files. In addition to this, we used CherryPy to expose the journey data from the server.py file to HTML and JavaScript files.

It was at this point in the project that we were given creative freedom to decide how we wanted to present our data, and after I did some research I learnt how to implement the OpenStreetMap and OpenLayers API into a webpage. This offered a great deal of freedom into displaying journey waypoints and rendering extra details onto the map.

The prototype added coloured markers representing each user for all the locations in the database. Just from this a user can see patterns and assume journeys, but it became difficult to tell where one journey ended and where another began.

Due to sensitive data being displayed, screenshots of the interface are available upon request.

To add further clarity, another layer was added to the map that drew lines between each point, stopping when the journey did. While this wasn’t perfect, it made it much clearer to see the different journeys.

Web Interaction

The final feature of the prototype was a simple sidebar that would allow the user to select a user to view, and all other location waypoints belonging to other users would be hidden.

A bug in the system that we didn’t have time to fix was that while each waypoint on the map was a separate HTML object, the lines were drawn directly on the map SVG, which couldn’t be removed through conventional methods. If we had more time to work on the project, this would be a priority fix.

Overall, the project was successful and received a first.