Recreationally overengineering my location history(overengineer.dev)
overengineer.dev
Recreationally overengineering my location history
https://overengineer.dev/blog/2025/08/19/overengineering-location-history/
7 comments
That's a wicked cool visualisation. I love it!
I have underengineered a similar problem with Owntracks, a Python receiver logging the location to a daily GPX file, and a static site generator generating daily map pages out of that data.
My goal was radically different: have everything saved in standard format, along with my other synced personal files, and turned into a static site. The static site is a daily diary augmented with my other activities. Owntracks is multiplatform and absurdly reliable.
I have underengineered a similar problem with Owntracks, a Python receiver logging the location to a daily GPX file, and a static site generator generating daily map pages out of that data.
My goal was radically different: have everything saved in standard format, along with my other synced personal files, and turned into a static site. The static site is a daily diary augmented with my other activities. Owntracks is multiplatform and absurdly reliable.
Mine just runs mosquitto_sub | gzip > $(date --iso=seconds).gz
Love the visualization, and the scenario of sharing your real-time location with anyone is important. I don’t know if Uber has that built-in, but Didi (in China) does and I use it frequently.
If anyone’s looking for a more plug-and-play option on iOS, I’ve been using Arc Timeline for nearly two years and it just dumps reasonably accurate .gpx files into your iCloud Drive without using too much battery. I use it for visualizing working locations and other activities on a weekly timeline.
If anyone’s looking for a more plug-and-play option on iOS, I’ve been using Arc Timeline for nearly two years and it just dumps reasonably accurate .gpx files into your iCloud Drive without using too much battery. I use it for visualizing working locations and other activities on a weekly timeline.
Even though it is at overengineering.dev, loved this pragmatic and simple approach:
I have implemented the most advanced client-side error-handling technique ever: window.location.reload().
Very cool. I did a similar but much less engineered and artistically inclined visualization using Bokeh in Python a few years ago: https://github.com/DataDrivenAngel/GDataViz
Looks awesome and I love the approach! About a year ago, I went through pretty much the same process and built Dawarich, although it's only now I'm starting touching the topic of sharing location publicly, not just recording it for further visualization.
Great work!
Great work!
1. Set up a region around the user's current location. If they exit it, note the location and set up another one around that location. This will give you around 100m accuracy, which is the minimum diameter of the monitored region.
2. Set up regions in various cardinal directions that nearly-or-just-barely overlap. If they enter one of those regions, note the location and set up another set around the current location. This can give you something closer to 50m accuracy.
For (2), this is how I did it in the Home Assistant iOS app, largely for zones that people wish to monitor which are smaller than 100m. You can find some of the annoying math here[1] (and there's tests all over for it), the logic for setting up regions here[2], and computing them here[3].
[1]: https://github.com/home-assistant/iOS/blob/master/Sources/Sh... [2]: https://github.com/home-assistant/iOS/tree/master/Sources/Ap... [3]: https://github.com/home-assistant/iOS/blob/2dfbe3c0e52a30417...