Building map based apps - The Camino

Building map based apps - The Camino

Architecture of a full map based solution.

·

3 min read

A few months ago I walked the Camino de Santiago from St. Jean Pied de Port in France to Santiago de Compostela in Spain - around 750km over 5 weeks. I wanted a way for my family to track progress and to be able to share photos.

I know there are plenty of existing ways to do this, but I (a) wanted to build something and (b) expected to be offline most of the day so I needed something that would work in a disconnected/semi-connected mode.

I had several requirements :

  • Would allow me to take photos offline while walking and upload them later when connectivity is available.

  • Longitude and Latitude are extracted automatically from photos.

  • The solution should be low cost (near $0) to run and low maintenance.

  • Something I could build in a day or two (as I left it to the last minute)

This is what was built:

  1. A very simple .Net MAUI application on my phone. Allows a picture to be taken in real-time OR selected from existing images.

  2. The JPEG is sent to a blob storage account. This is typically a ~4MB file per image so needs fair bandwidth.

  3. An Azure function is triggered by the presence of a new file. The function extracts the longitude and latitude from the photo EXIF properties and stores them in a SQL table along with the date/time and filename.

  4. A static web app hosts the html/javascript.

  5. The javascript makes an API call to a second Azure function which queries the database and returns an ordered list of (long/lat/date/time/filename) in JSON format.

  6. This is added as a new layer on Bing Maps with a line showing the route and dots showing where photos were taken.

  7. Hovering over a dot loads the JPEG from blob storage and displays it as a popup.

The result looked like this :

In particular :

  • It took only a few seconds from taking/uploading a photo to it being on the map and visible.

  • The overall solution is loosely coupled and modularised. Any failure (e.g. of the Azure function) would simply mean that the photos queue up on the storage account and are processed in bulk when the function comes back.

  • It also means architectural components and languages can be readily changed. I prefer to code in C#, so Azure functions and .Net MAUI enable that. But switching the mobile client to Swift/Java or the database from SQL to Cosmos would be invisible to the rest of the solution.

  • Nearly everything is serverless or zero cost except the SQL database which costs a few dollars a month. There were cheaper options available than SQL - but did I mention I was in a hurry? - so I went with what I knew.

While the selection of any specific component here is subjective and an equivalent solution could be built with entirely different pieces (e.g. Swift/EventGrid/LogicApps/Cosmos/Kubernetes) the basic pattern is fairly common when using a cloud based architecture.

Example : Image classification on Azure - Azure Architecture Center | Microsoft Learn

Next up : The .NET MAUI app and blob storage in Building Map Based Apps - The Camino Part 2