How a quest for offline maps turned into an Android app, 3D terrain, heart-rate tracking, and an increasingly unreasonable WordPress ecosystem.
I’ve wanted to build my own hiking app for years.
Not because the world desperately needs another hiking app. There are plenty of them, and some are very good. I’ve used AllTrails and other GPS applications for years, and they’ve generally served me well.
But I’ve also spent years maintaining my own hiking website, working with GPX files, creating interactive trail maps, and documenting hikes. Somewhere along the way, I developed some very particular ideas about how I wanted all those pieces to work together.
I’d experimented with building my own app before. Nothing had quite worked out.
Then I got interested in bringing offline maps to my hiking website.
That seemed like a reasonably manageable project.
Narrator: It was not.
The Trouble With Maps
My hiking website has used Leaflet, an open-source JavaScript mapping library, for years.
Leaflet is great. It allowed me to display GPX tracks over topographic maps, satellite imagery, and other basemaps, complete with elevation profiles and trail markers.
I was pretty happy with it.
But I wanted more.
Specifically, I wanted offline maps.
When you’re hiking somewhere with no cell service, an interactive map that depends on an internet connection is about as useful as a screen door on a submarine. I’ve encountered plenty of situations where offline navigation would have been helpful, and I wanted to explore making maps available without a connection.
Initially, I was thinking about the website. Could I package map tiles so visitors could download them for offline use? Could I make it part of a progressive web app?
That led me into the fascinating and occasionally maddening world of map tiles, caching, MBTiles, PMTiles, and geographic bounding boxes.
And somewhere in that research, I began wondering whether I should take another shot at building an actual Android hiking app.
After all, the website was only half the equation. I still needed something to record the hikes in the first place.
And if I could build the app myself, I could make it work exactly the way I wanted.
Famous last words.
Learning Kotlin the Hard Way
I’m a web developer. I’ve spent years working with PHP, JavaScript, databases, APIs, and various content management systems.
Android development was another animal entirely.
The application would be written in Kotlin, a language I had very little experience with. I understood the programming concepts and knew what I needed the application to accomplish, but the particulars of Android architecture, background services, permissions, and application lifecycles were unfamiliar territory.
So I started learning by building.
The first objective was simple: record GPS coordinates, save them as a GPX file, and keep recording when the phone screen turned off.
That last part is surprisingly important. A hiking app that stops recording when you put your phone in your pocket has a fairly significant design flaw.
Once I had the basic recorder working, I added the ability to load a previously created GPX file for navigation while recording a new track.
This was particularly useful because I frequently scout routes before hiking them. Sometimes I’ll draw a planned route manually, then use it to navigate when I’m actually on the trail.
The scouting route and the recorded hike are two different things. I wanted the application to understand that distinction.
And slowly, the thing started coming together.
I could record a hike, follow a planned route, save the result, and upload the GPX file to WordPress.
It was starting to feel like a real application.
Then I started getting ambitious.
Goodbye, Flat Earth. Hello, MapLibre.
For years, my hiking maps had been essentially two-dimensional.
They were good maps, but they were flat.
During my research into mapping technologies, I discovered MapLibre, another open-source mapping engine with some seriously interesting capabilities.
Most exciting was its support for three-dimensional terrain rendering through its web-based engine.
I’m a photographer, a hiker, and a map nerd. The idea of seeing an actual landscape rise out of the screen, with mountains, valleys, and a GPS route draped across the terrain, was irresistible.
Getting there wasn’t entirely straightforward.
MapLibre’s native Android implementation and its JavaScript implementation didn’t support exactly the same features. That led me to experiment with a hybrid approach, using a WebView for the more sophisticated 3D terrain rendering while retaining native mapping capabilities for other functions.
There were technical hurdles, rendering experiments, and more than a few moments of wondering whether I’d made a terrible architectural decision.
But then it worked.
And holy shit.
After years of looking at flat Leaflet maps, seeing actual terrain rendered in three dimensions was amazing.
I could tilt the camera, rotate the landscape, and see the route in the context of the mountains surrounding it.
Then I added an animated flyover.
Load a GPX track, start the flyover, and the camera follows the route across the terrain.
Completely unnecessary for recording a hike?
Probably.
Absolutely awesome?
Yes.
And I wasn’t about to stop there.
Offline Maps, Finally
Meanwhile, the original reason for this whole adventure hadn’t gone away.
I still wanted offline maps.
After experimenting with different mapping technologies and storage formats, I got offline MBTiles working in the Android application.
That was a major milestone.
MBTiles allows map tiles to be packaged into a database file that can be stored locally. Instead of depending on a remote tile server every time I move around the map, the application can read the necessary map imagery from the device.
Exactly what I wanted for hiking in areas without reliable service.
Interestingly, getting offline maps working in Android changed how I thought about implementing them on the website.
Originally, I’d considered allowing visitors to define their own geographic bounds, zoom levels, and other settings to generate an offline map package.
That was a lot of complexity to hand to somebody who probably just wanted to go hiking.
I eventually decided to postpone offline mapping on the website and take a more curated approach when I return to it.
Rather than making visitors configure everything themselves, I’ll prescribe appropriate offline map packages for particular hikes or regions.
Less fiddling with settings. More hiking.
The website implementation is still on the roadmap, but getting the Android version working was a big win.
And Since We’re Here, How About the Weather?
Once the mapping foundation was in place, I started thinking about other information that would be useful while hiking.
Weather seemed like an obvious addition.
So I added a weather checker and a radar overlay.
Being able to see weather information alongside the map is useful, particularly when you’re heading into unfamiliar terrain or trying to decide whether that ominous-looking cloud is about to ruin your afternoon.
The radar overlay was particularly satisfying because it made the map feel less like a static navigation tool and more like a living picture of the conditions around me.
Of course, these features depend on connectivity for fresh weather information. They aren’t a replacement for checking the forecast before heading into the wilderness.
But they’re another useful addition to the growing collection of things Hikenado can do.
And, let’s be honest, another excuse to play with maps.
The World’s Nerdiest Field Notebook
One of my favorite features came from a completely different problem.
When I’m hiking, I frequently notice things I want to mention later when writing about the trail.
A washed-out section. An interesting landmark. A confusing intersection. A particularly good view. Something that might be helpful to somebody planning the same hike.
Unfortunately, my ability to remember those observations after several hours of hiking is less impressive than I’d like.
So I built geolocated audio field notes into Hikenado.
While recording a hike, I can dictate an observation into my phone. The application saves the audio recording along with its geographic location.
When I finish the hike, the app packages the GPS track and field notes together for upload to WordPress.
And here’s where things get really cool.
I integrated the OpenAI API into my custom WordPress plugin, allowing the uploaded audio recordings to be automatically transcribed into text.
Instead of sitting at my computer trying to remember what I saw at mile four, I have a collection of actual observations recorded on the trail, complete with location information.
Then I took it another step further.
I added another API integration that can use the collected hike information and field notes to generate a preliminary draft of the blog post.
It doesn’t replace my writing. I still want to tell my own stories, and I certainly don’t want software inventing trail conditions or experiences that never happened.
But having a structured starting point based on information I actually collected is incredibly useful.
The whole process now works something like this:
Record the hike → Dictate field notes → Save the package → Upload to WordPress → Process the GPS track → Transcribe the audio → Generate a draft → Review and publish.
This was one of those features that started as a convenience and ended up changing the entire workflow.
I wasn’t just building a GPS recorder anymore.
I was building a system for documenting hiking experiences from beginning to end.
WordPress Got a Serious Upgrade, Too
Of course, the Android app is only half the story.
My hiking website runs on WordPress, and over the years I’ve developed quite a few custom tools to support it.
As Hikenado evolved, I began consolidating and expanding that functionality into a custom WordPress plugin.
One major component is the GPX processor.
GPS recordings can be messy. Devices occasionally record inaccurate coordinates, create strange spikes in elevation, or produce tracks with unnecessary points.
The processor helps clean up the data and enrich it with more useful elevation information.
Then there’s the GPX editor.
Instead of exporting a file to another application every time I need to correct a route, I can work directly with the track on an interactive map in WordPress.
Delete points. Move them. Add points. Correct the route and save the result.
This is especially helpful when the GPS decides I somehow teleported several hundred feet into the woods while standing still.
The Create Hike interface ties the whole publishing process together, handling uploaded tracks, field notes, transcription, and draft generation.
On the public-facing side, the plugin supports interactive trail maps, elevation profiles, route information, and caution markers.
And MapLibre has opened the door to a whole new generation of map presentation.
I spent years building maps with Leaflet. Seeing how far I could take the experience with a newer rendering engine has been one of the most satisfying parts of the project.
Making Exercise More Interesting Than Exercise
There’s another reason I decided to tackle Hikenado again.
I needed to get off my ass.
Since our son was born, our hiking adventures have become fewer and farther between.
It’s not that we’ve lost interest. It’s just that hiking with a small child presents some logistical challenges, particularly when your idea of a good hike involves several miles, substantial elevation gain, and terrain that isn’t exactly stroller-friendly.
Even some of our shorter hikes are still a bit much for him.
So we’ve been doing less hiking.
And I’ve been doing less moving.
That’s a problem, because we’re heading to Patagonia in November, and we have some serious hikes planned.
Patagonia isn’t exactly the place you want to discover that your cardiovascular fitness has been replaced by a vague familiarity with the refrigerator.
I knew I needed to start training.
And I also knew myself well enough to recognize that I might be considerably more enthusiastic about exercising if I could turn it into a technology project.
Enter Hikenado.
Now I have a reason to go walking beyond the obvious health benefits.
I get to test the application. Record tracks. Experiment with features. Collect data. Look at maps. Analyze the results.
And then I get to bring everything into WordPress and play with it some more.
It’s exercise disguised as software testing.
Which, for me, is apparently a highly effective motivational strategy.
Then I Made the Map Show My Heart Rate
Once I started thinking about Hikenado as a training tool, I wondered whether I could record heart-rate data alongside the GPS track.
I wanted to see not just where I’d walked, but how hard my body was working at different points along the route.
That meant learning how to communicate with a Bluetooth Low Energy heart-rate monitor.
My first attempt involved a COOSPO monitor that proved less than cooperative.
Eventually I bought a Polar H10 chest strap.
The app discovered it almost immediately.
After working through the Bluetooth integration, Hikenado was able to capture heart-rate readings and attach them to individual GPS trackpoints using standard GPX extensions.
On one test walk between Noblitt Park and Mill Race Park, the app recorded 1,297 GPS trackpoints.
Every single one contained heart-rate data.
Then I updated the WordPress processing pipeline to preserve that information and added visualization that could show heart-rate intensity along the route.
Suddenly, I could look at a map and see where I’d been cruising comfortably and where I’d been working harder.
The route was no longer just a record of where I went.
It was a record of how the hike affected me.
For somebody trying to improve fitness before tackling the mountains of Patagonia, that’s genuinely useful.
And for somebody who enjoys turning ordinary activities into elaborate data projects, it’s practically irresistible.
There Were Some Spectacularly Annoying Problems
I don’t want to make this sound like everything worked beautifully from the beginning.
It did not.
There were Android build errors, Kotlin concepts I had to learn from scratch, Bluetooth connection failures, mapping-engine limitations, and occasional application freezes.
At one point, Android informed me that Hikenado kept stopping.
I pressed Wait.
And waited.
And waited some more.
Eventually, the application finished processing the hike package and opened the WordPress workflow.
Apparently, making the Android main thread do a bunch of heavy file processing wasn’t a particularly brilliant design decision.
Who knew?
Well, probably quite a few Android developers.
There were also plenty of architectural lessons.
Some mapping features were easier to implement in JavaScript than in native Android. Offline mapping introduced different requirements than online mapping. Working with GPX extensions required paying attention to how data moved through multiple systems.
And as the project grew, the codebase became increasingly complicated.
One Kotlin fragment in particular turned into the software equivalent of the Winchester Mystery House. Every time I wanted to add something, I had to figure out which hallway led to the room I was looking for.
But that’s part of what I enjoy about building things.
I knew what I wanted the software to accomplish. Figuring out how to make it happen meant learning new technologies, testing ideas, making mistakes, and occasionally throwing out an approach that wasn’t working.
Every solved problem made the next one a little less intimidating.
Or at least made me sufficiently overconfident to attempt it.
The First Time Everything Worked Together
One of the most satisfying milestones wasn’t the 3D terrain or the animated flyover.
It was the first time the entire workflow worked from beginning to end.
The Android app recorded the hike. Background tracking worked. The GPX file saved correctly. The hike package uploaded to WordPress. The GPX processor did its job. The audio notes were transcribed. The draft-generation system produced a starting point for a trail report.
Everything worked together.
That’s when Hikenado stopped feeling like a collection of experiments and started feeling like an actual application.
I even compared one of its recorded GPS tracks against a commercial hiking app.
The results were encouraging.
I wasn’t expecting to outperform an established commercial product. I just wanted something accurate and reliable enough that I could trust it on the trail.
And increasingly, that’s what I had.
The Best Part Is That I Actually Want to Go Hiking
There’s still plenty I want to build.
I want to continue improving offline mapping, expand the terrain visualization, refine the training metrics, and make the interface more polished.
I’d love better route awareness, including how much distance and elevation gain remain on a planned hike.
The WordPress site will eventually get its own curated offline map packages.
And I’m sure I’ll come up with another dozen features that seem completely reasonable right up until I start implementing them.
But the biggest success might not be any of those things.
It’s that Hikenado has given me another reason to get outside.
I enjoy building the app. I enjoy testing it on actual hikes. I enjoy looking at the data afterward and turning it into maps, charts, and trail reports.
The whole thing has become a self-reinforcing cycle of exercise and nerdiness.
Go hiking so I can test the app.
Test the app so I can collect data.
Collect data so I can build more interesting features.
Build more interesting features so I want to go hiking again.
Somewhere in there, I might even get into decent shape.
I started this project because I wanted offline maps on my hiking website.
I ended up building an Android application, a custom WordPress publishing pipeline, geolocated audio transcription, AI-assisted draft generation, 3D terrain maps, animated flyovers, weather overlays, and heart-rate visualization.
And I still haven’t added offline maps to the website.
Sounds about right.
At least now I have a pretty good excuse to go for a walk.