ArcGIS Maps SDK for Qt

Creating an application to identify climbing locations using a weather forecast API

This blog introduces a common challenge facing rock climbers and gives an example of how the Native Maps SDKs were used to develop a tool to help.


One of the greatest challenges to having a successful day climbing in the mountains (Figure 1) is assessing the weather, which varies over short distances and time frames, especially in Scotland where I live. To find the mountain with the best weather, and therefore the best chance of a successful day’s climbing, I spend hours reviewing the forecast from multiple sources. This is inefficient and error-prone.

Figure 1: Exceptional climbing on Triple Buttress, Beinn Eighe, NW Scotland..

To make this process more efficient and reliable, I’ve created an Android application using the ArcGIS Maps SDK for Native Apps, which requests weather forecast data from a RESTful API and stores this in a custom data structure. The ArcGIS Maps SDK for Qt allowed me to create both desktop and mobile applications, which meant I could use the application on my laptop at home and on my phone while on climbing trips. I also used the Qt SDK as it’s the development framework I’m most familiar with. However, the same workflow and principles apply for the other Native Maps SDKs (Java, .NET, Swift and Kotlin). The application makes accessing forecast data quick and automates some of the review process.

In this blog I’ll:

The source code for the application which I’ll discuss is available on AndrewBladon’s QtWeatherApp GitHub repository.

The Challenge

Most people fit climbing around jobs and other commitments. Often, this means climbing within a given time frame, such as the weekend. When restricted to a given day or days, the challenge becomes finding the mountain and climb where the weather conditions are suitable. However, the relationship between the weather and the condition of climbing routes is complex. Here’s a couple of the relationships that are considered:

To assess these relationships requires an understanding of the spatial and temporal variations of several parameters (e.g. rainfall, wind speed, wind direction, and visibility) across a region as well as knowledge of the climbs (e.g. rock type, cliff orientation, and length of climb). Modern forecast sources (e.g. Met Office, Mountain Weather Information Service) present forecast data in multiple useful formats (e.g. tables and time-series maps). However, it’s challenging to gain the required understanding of multiple parameters across a region. This challenge is especially prevalent in Scotland, where I live, because the mountains are low (<1345m) and exposed to Atlantic weather systems. This results in unstable weather that varies rapidly over short distances.

Figure 2: Despite following a long manual process to assess the conditions, it is common to have mis-judged: a) abseiling from Slochd Wall on Beinn a’Bhuird, Cairngorms, Scotland after finding the key section of the climb covered in wet, slimy moss and unclimbable; b) climbing carefully through streaks of water on the lower section of Minus One Direct, Ben Nevis, Scotland.

Current Weather Review Process

Until now, I’ve been collating and reviewing the forecast data manually. This involves looking at the forecast for multiple locations and iteratively building a mental model of the weather conditions for the given timeframe. As mentioned previously, this is time-consuming and error-prone. Despite doing this for many years, the challenge of characterizing the relationship between multiple dependent variables often results in mis-judgements (Figure 2). Mis-calculations, are especially frustrating when on long (≥1 week) trips to the bigger mountain ranges (e.g. European Alps), as such trips require significant time and effort to organise and are costly. In these scenarios it’s especially important to be able to make decisions quickly and efficiently. Following a challenging trip to the Western Alps in 2022 (Figure 3) and motivated by a planned two-week trip to the Dolomites in Northern Italy in September 2023, I decided it was time to reduce the chances of weather-related issues and created a tool that made this process more efficient and reliable.

Figure 3: Sheltering from an especially heavy downpour of rain in Chamonix, France.

The Conditions Navigator Application

My aim was to create an application that worked on my Android phone which automatically retrieved forecast data from a weather API and guided us towards mountains where the weather was suitable for climbing. To achieve this, I created an application called the Conditions Navigator using the ArcGIS Maps SDK for Qt, which was deployed to my Android phone (Figure 4). The Qt Maps SDK is a great tool for efficiently creating cross-platform applications, so I could use the application on both my laptop and phone.

Figure 4: Screen recording of the Conditions Navigator application being used on an Android emulator, with the two main functions being demonstrated: 1) viewing forecast data for a location selected by the user, and 2) categorising mountain conditions as good, marginal, or bad for a given day or days according to a set of hard-coded criteria. Mountain conditions are indicated by colouring the pin symbol as green, orange, and red for good, marginal, and bad conditions respectively. Uncategorised mountains are shown with the default dull red coloured pin symbol.

The fundamental building block of the application is a map with a topographic basemap, which provides an application user with information about the terrain adjacent to the summit of each mountain. The map acts as a canvas onto which I built all other functionality.

The second most important component is a representation of each mountain where there is climbing. Each mountain is symbolised on the map using a dull-red coloured pin symbol and represents a custom data structure that stores and curates the weather data for that mountain. To achieve this, I defined a template for my custom data structure (i.e. a custom class) which I called Mountain. The data structure includes:

When the application is initialised, a static free function is called that returns a list of Mountain objects. This list of Mountain objects is hard-coded into the application, including information about each mountain such as the location (latitude and longitude) and elevation. This means Mountain objects are created each time the application is started – the application is not reliant on a map published online (i.e. web map).

Once the list of mountains is created, the application performs the following initialisation workflow for each mountain (Figure 5):

A label is also added to display the name of the mountain using the LabelDefinition class and a listener is set up using the mouseClicked and touched events on the map view to identify when a user taps the map (implementation details can be reviewed on AndrewBladon’s QtWeatherApp repository).

Figure 5: Schematic diagram outlining the key elements of the ConditionsNavigator application. The initialisation workflow (blue arrows) comprised the following steps for each mountain: 1) Create a symbol and add it to the map, 2) send HTTPS request to forecast provider REST API, 3) wait for the JSON response, and 4) process the response and organise data into custom data structure. Once the application was initialised, a user could trigger two main actions (red arrows): displaying a forecast for a mountain when it was selected by the user and applying a filter to all mountains to identify areas suitable for climbing.

Once the initialisation workflow has been completed, forecast data is available for each mountain and the application is ready for user-interactions.

The application has two main functions:

Parameter Good condition Marginal condition Bad condition
Daily Rainfall [mm] < 1 1 – 5 ≥ 5
Windspeed [km/h] < 20 20 – 40 ≥ 40
Description of most severe weather [World Meteorological Organnisation code] “Clear”, “Mainly Clear”, “Partly cloudy”, “Overcast”, or “Unknown” “Fog”, “Drizzle, “Rain”, “Snow”, “Rain Showers”, or “Snow Showers” “Thunderstorms”

For more information about how the application was implemented, you can review the code as part of AndrewBladon’s QtWeatherApp GitHub repository. The mountains in this version of the application are the Munro’s – the 282 highest mountains in Scotland with an elevation greater than 914.4m (3000ft). The source code can be used to deploy your own version of the application or as a starting point for developing your own application.

How the Conditions Navigator helped make my holiday a success

As mentioned previously, the Conditions Navigator application was initially developed for a climbing holiday to the Dolomites, Northern Italy, in early September 2023. Even before we left Edinburgh, the application started adding value. Because we had easy access to forecast data for the entire mountain range, we could quickly and easily monitor the weather conditions during the week prior to our departure and assess the weather for the first week of our trip. We could balance this easily with our other commitments (e.g. work and family). With easy access to the weather forecast and an understanding of the recent weather history, which we gained by monitoring the forecast for the week prior to our departure, we could start to identify some initial climbing objectives before leaving home.

While in Italy, the application continued to help. Very little of our time was spent reviewing forecasts. We were able to identify areas in the mountain range where the weather was good and make informed decisions quickly. This meant we had plenty of time to enjoy the local beer and pizza! Because we had decided to camp in order to be flexible, we could move to areas where the weather was favourable and there were climbs we wanted to do. This meant we were able to climb on 10 out of the 11 days we had available and in three different regions: Cortina d’Ampezzo, Canazei, and Arco. Overall, a very successful trip!

Photos from two of the more significant climbs we did on Cima Grande (2999m) and Tofana di Rozes (3225m) are shown in Figure 6 to Figure 11. To see more photos from the trip, visit my Climbing in the Dolomites StoryMap.


I’ve introduced one of the challenges faced by people planning to rock climb in the mountains, which is assessing the mountain weather conditions. I also gave an overview of the process I currently follow to overcome this challenge. I’ve shown that there are a number of variables to consider and tried to highlight how mistakes and mis-judgements are common due to the size and complexity of the task. I then introduced the Conditions Navigator, which is an application created using the ArcGIS Maps SDK for Qt. The application aims to make the process of reviewing the mountain weather conditions more efficient and reliable. Finally, I described how the application helped make a recent climbing trip to the Dolomites in Northern Italy a success.

To find out more about developing geospatial applications using Esri’s developer technologies, including the various developer API’s available as well as samples and tutorials, visit Esri’s ArcGIS Developers page. To learn more about the application discussed in this blog, visit AndrewBladon’s QtWeatherApp GitHub repository.

Figure 6: The Dibona Arete on Cima Grande (a) and the Southeast Arete on Tofana di Rozes (b). The routes are indicated by the red lines (dashed line indicates the route is not visible – e.g. behind a rock buttress). The position of photo’s shown in the figures are shown.
Figure 7: Loïc Galland climbing up to a belay mid-way up Cima Grande (see Figure 6 for approximate location).
Figure 8: The author climbing high on Cima Grande (see Figure 6 for approximate location). The stunning tower of Cima Piccola is visible in the background.
Figure 9: Looking west towards Cima Ovest from the summit of Cima Grande (see Figure 6 for approximate location). Note the glider in the dashed red circle).
Figure 10: The author climbing on Tofana di Rozes (see Figure 6 for approximate location).
Figure 11: Looking south past the summit cross on Tofana di Rozes.

About the author

Andrew Bladon

Andrew is a Software Engineer working on the ArcGIS Maps SDKs for Native Apps in Esri’s Edinburgh R&D Centre. Andrew helps bring the latest features available in ArcGIS location services into the core C++ business logic used by the Native Maps SDKs. Andrew has a Bachelor of Science and PhD in Geology, and prior to working with Esri he spent seven years working as a Consultant and Product Engineer for a geological modelling software company.

Inline Feedbacks
View all comments

Next Article

Introducing the Fieldwork Handbook

Read this article