Kategorien
Allgemein

Heatmaps im Eigenbau

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.

Eine Antwort auf ÔÇ×Heatmaps im EigenbauÔÇť

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht ver├Âffentlicht. Erforderliche Felder sind mit * markiert.