Heute mal wieder ein Blick hinter die Kulissen: auch in der Vergangenheit hatte ich hier und hier schon darüber geschrieben, wie man Strava und Komoot verbinden kann um die Strava Heatmap bei der Routenplanung berücksichtigen zu können.
Für zahlende Strava-Kunden gibt es außerdem neben der „global heatmap“ noch eine personalisierte Variante, die also darstellt, wo man selbst schon alles gewesen ist (und dementsprechend, wo noch Strecken darauf warten entdeckt zu werden).
Nun ist es aber so, dass ich seit einer Weile um die großen, zentralisierten sozialen Medien (Twitter, Facebook) einen Bogen mache und letztlich nur noch Mastodon (bzw. konkret die wue.social Instanz von Ralf) nutze. In dieses Bild passt natürlich auch nicht der Routen-Upload auf Strava und Komoot — und so kam es letztlich zu diesem Blog als „sharing Alternative“ zu Komoot (und z.B. auch der Kilometerstatistik etc.).
Jetzt fand ich die personalisierte Heatmap von Strava aber schon toll — also habe ich mir meine dezentrale Variante selbst gebaut. So sieht das Ergebnis aus:
In leichtem rot die Strecken, auf denen ich bisher nur einmal war … wenn ich an der Stelle schon ein paar mal war, dann sattes dunkelblau.
Technisch gesehen sind das selbst gerenderte overlay tiles, die man auf beliebige OpenStreetMap Karten (und theoretisch auch Google) legen kann.
Ich hatte mich dann erstmal nach bestehenden OpenSource-Lösungen umgesehen, … und feststellen müssen, dass das eher eine Nische ist. Nach einer Weile bin ich auf das Projekt „gheat“ gestoßen, … letzte Version vom April 2008. Und das setzt auf einen ebenso alten Python Web-Server (Aspen), von dem ich zuvor noch nie gehört hatte. Dort verlinkt ist auch ein Fork, der das ganze als Python CGI Script umgesetzt hatte (wobei der Code ebenso ziemlich alt ist).
Der Fork setzt auf eine MongoDB als Backend, die 2009 erst rausgekommen ist. Das muss definitiv ein early adopter gewesen sein 🙂
So oder so, der Plan stand dann relativ fest. Den alten Python Code zum Laufen bekommen, einen fastcgi-wrapper drumrum und einen modernen nginx davor. Das ganze in Docker verpacken und eben eine MongoDB daneben. Gesagt, getan. Stellt sich raus, dass das original gheat relative fette Kleckse zeichnet (für jeden einzelnen Punkt des GPX Tracks) — also im Format eher so breit wie eine Siedlung statt einer Straße.
Hat eine Weile gedauert zu verstehen, wie das gheat intern arbeitet, … aber eigentlich ist der Ansatz cool: nämlich zweischrittig. Für jeden Punkt des gpx wird erstmal eine (halbtransparente) „dot.png“ (das Teil der Programmquellen ist) auf eine transparente Leinwand projeziert. Das führt dazu, dass dieses Zwischenbild um so dunkler wird, je mehr Punkte gezeichnet werden bzw. um so dunkler/opaker das dot.png ist.
Im zweiten Schritt wird der Alphakanal dieses „Bildes“ wieder ausgelesen und die eigentliche Heatmap unter Berücksichtigung des gewählten Farbverlaufs generiert.
Letztlich ein interessanter Ansatz — heißt nur, dass ich zum Lösen der Klecksproblematik nicht den Code anfassen muss, sondern meine (nicht vorhandenen) Gimp Skills auspacken muss.
Naja, hat dann schon irgendwie funktioniert 🙂
… und die Belohnung ist die oben gezeigte Heatmap. Die ausreichend flott für on-the-fly Generierung ist und seither mit auf dem Webserver lebt. Den aufgefrischten und modifizierten Code findet ihr (ebenso denzentral) hier auf meiner Gitlab Instanz.
