HXRC Team: Data Visualisation in Urban Setting part 2 – Leppävaara Expansion

Text by Tino Behnen and Sonja Sillanpää

This project is a continuation of the previously done work for the City Data project. The City Data project set out to create a digital twin of the Myllypuro Campus and its surrounding buildings to better visualize data related to the area, including weather and traffic related statistics on top of building information. The web application featured a navigable 3D map which had models for buildings that could be interacted with to open panels for inspecting building information. The application also featured realtime simulations of current weather conditions and public vehicle movements. The project, being a proof of concept (POC), was left open for further development in some areas, and on a technical level, was created to be expandable on the existing features, like when adding buildings and geographical areas, for example. 

Trainee introduction: Tino Behnen

Hello, my name is Tino Behnen. I’m a Programming and Developer trainee here at Helsinki XR Center, as well as a last year student at Metropolia UAS, specializing in Game Development.

In this project, I was responsible for most of the project’s codebase and feature development. This project was my very first React application that I’ve worked on, so it was a fresh and exciting opportunity for me to learn about web development on a deeper level. I did have some previous knowledge about developing with React from University courses, but actually getting to work on and continuing a project from a solid foundation from a previous development team really gave me a better understanding of how these kinds of web applications are structured. I’ll dive into the development in more detail in the technical portion of the blog post. Overall, I’m quite satisfied with my involvement in the project.

The quest

This project was carried out in cooperation with the City of Espoo as part of the ENPA (Energiapalvelumalli alueille) initiative. Following their plans for developing the Leppävaara central area, the goal was to add the new planned buildings to the existing application and create an easy way to view the area and its data. This would entail modeling the buildings and giving them all the interactive features on the map that the previously implemented buildings already had. Features like the ability to click on buildings and to render different kinds of elements and panels for each of them. On top of giving the new area and structures the same functionality as what the previous version had, we also wanted to add new features and improvements. A major focus was on displaying the consumption data of the buildings in a way that would be easily readable and flexible in timescale. Later on, we also wanted to have the building’s production sources for electricity to be somehow visible and have it also be dynamic so that one could see how much of the building’s own consumed energy is produced locally by the building itself via solar energy.

Trials and triumphs

Coder’s perspective

 In this section, I will briefly go over the most important parts of the project in which I was personally involved as a coder:

New features

As mentioned, one of the major features of this project was the info panels and the visualisation of consumption and production data for the buildings. To visualise the data, we decided to go with a graph approach where one could see a timeline of both the consumption and production. Instead of developing our own line graph logic, we went with a publicly available library called Tremor, which provided customizable LineChart components with built-in tooltip support and legend management, as well as ready-made logic for a dynamically scaling timeline based on given data.

 Info panel with the electricity tab in focus.

While using the library did solve most of the issues when it came to implementing the graph, it did cause some trouble for making the graph responsive, where some elements wouldn’t scale with the parent panel. Making the panel responsive in the way I wanted was a little bit challenging in itself, with no previous knowledge of responsive design. I ended up making a solution where all the child elements of the info panel would scale relative to its size by using “em” units for all scaling, which scales everything relative to the font size. This method kept the proportions the same for all of the panel’s child elements regardless of the size of the panel.

In addition to the graph, we also included a breakdown of production sources with the option to toggle local solar energy on and off, which dynamically updates both the graph visualization and production breakdown percentages. To handle the data, I made a formatter script that aggregates and processes data across different time ranges (day, week, month, year), calculates production source breakdowns, and handles data caching for performance.

Improvements

On top of the new features that I worked on, I made some additions to already existing elements. The energy cards were meant to be floating elements for showing monthly average consumption values above each building, respectively. The previous version did have this feature already, but it lacked the visuals that we were aiming for. To style them the way we wanted, the cards had to be rendered differently from how they originally were. In order to use CSS for styling the cards, we couldn’t use the already existing deck.gl text layer implementation. Instead, the card was made into its own element, which would be scaled and rendered correctly above each building.

Energy cards showing monthly consumption values of the buildings.

This took quite a bit of trickery to get it rendered at the correct coordinates and for it to move across the screen when navigating the map. The way I ended up implementing this was by converting the building coordinates into screen positions. Basically getting the pixel coordinates of the building and then rendering the energy card relative to that position. This would then get recalculated again each time the user moves or zooms the map. With this implementation and with the help of our Code Lead Alicia who did the CSS for the cards, we got them to work the way we wanted.

Now I will pass it off to Sonja, who will tell about her experience on the project as the artist.

Artist’s perspective

I started my part of the project by cleaning a big 3D model of the Leppävaara area. The first task was to separate all the buildings from the ground geometry, since it was all merged together. The main focus was on the new buildings which would be built in the future, so I was more focused on cleaning them. The other buildings already existed in the application as realtime information, so the duplicates could be deleted.

We proceed on these new two buildings, Voimakortteli and Keskuskortteli, that needed to be more polished, and some surrounding buildings that only needed cleaner geometry. It was important to add details in the two main buildings. For reference I had urban city planning documents, which included information and several pictures of the buildings. It was still difficult to see the buildings from close up, so making them one-on-one accurate wasn’t possible. However, the focus of the application wasn’t the 3D models. The most important thing was to make the main details prominent and recognizable. I had to also take into consideration the performance of the application, so that the models couldn’t be heavy and they had to have as little geometry as possible. It was tricky, since these two buildings were full of windows, and I had to make them match the previously made Myllypuro campus building, which had a lot of details.

 Top image: Two main buildings before polishing. Bottom image: Two main buildings finished.

The geometry of the other buildings surrounding Keskuskortteli and Voimakortteli was easier to polish and clean. They didn’t have to have any windows or other details. Some of the buildings in the reference photos had solar panels and green roofs, which we also wanted to include. This way, it was also easy to see which new buildings would be built in the future. Also, for the new main buildings, it was important to add solar panels for reference.

The polished main buildings in the middle and the surrounding buildings with green roofs and solar panels.

There was a need to add some new UI elements to the application. Since there were already UI elements made by a previous Art trainee, Alma Hoque, I was able to use them and make the new UI elements to match the previous ones. Specifically, I had to make a panel for different energy consumption and production types (electricity, thermal, and water), which would show a graph of the specific data, and how they would change depending on the day, week, month, or year. It would also have a general information tab, which would have a small description of the building that is clicked in the scene. Overall, there wasn’t a lot of new UI to add. Lastly, there was also an interactive prototype made for quick visualization of the UI functionality.

Reflections

Looking back, the project was a success both in all the new things we picked up, as well as in the result we ended up with. Both of us got to do things that were out of our comfort zones, and were satisfied with what we learned. On top of growing as developers, we also made some great additions and improvements to the project, such as data visualisation, new 3D models for buildings, and UI designs. While the project could still use some polishing in some areas, we are proud of what we achieved and look forward to seeing the possible continuation of the project by future teams.

To see previous news about our trainees’ projects, head over to the Trainee news section.

Follow us on social media for more posts: Facebook | LinkedIn | Twitter | Instagram