Läufer, die eine Strecke planen, interessieren sich für Steigungen auf eine Weise, die sich anhand einer flachen Karte allein schwer beurteilen lässt, denn zwei Strecken gleicher Länge können sich völlig unterschiedlich anfühlen, je nachdem, wie viel Anstieg in ihnen steckt. Auf der Wunschliste einer Lauf-App stand monatelang ein Punkt ganz oben: das Höhenprofil einer geplanten Strecke anzeigen, bevor man sich entscheidet, sie zu laufen.
Die Routenfunktion der App erzeugte bereits eine Folge von Koordinaten, die einen geplanten Lauf beschrieb, erstellt aus einem Start- und einem Endpunkt und der eigenen Wegfindungslogik der App entlang echter Straßen und Wege. Was fehlte, waren Höhendaten für jeden Punkt entlang dieses Weges. /v1/elevation schloss diese Lücke direkt: Eine Liste von Koordinaten, in einer einzigen Anfrage gesendet, kam als passende Liste von Höhenwerten zurück, in derselben Reihenfolge und bereit, sie über der kumulierten Entfernung des Läufers entlang der Strecke aufzutragen.
Das resultierende Diagramm, Höhe über Entfernung, gab Läufern genau das, was der Funktionswunsch verlangt hatte: einen klaren Überblick, wo die Anstiege entlang eines geplanten Laufs lagen, wie steil jeder im Vergleich zum Rest der Strecke aussah, und einen Wert für den gesamten Höhengewinn, der neben Entfernung und geschätztem Tempo zu einer der zentralen Kennzahlen wurde, die für jede gespeicherte Strecke in der App angezeigt wurden.
Die Dichte der Abtastpunkte war hier für die Kostenkontrolle wichtig, ähnlich wie eine Radfahr-App dasselbe Problem angehen würde. Ein kurzer Lauf durch die Nachbarschaft brauchte recht häufig abgetastete Höhenwerte, um ein glattes, genau wirkendes Diagramm zu erzeugen, während eine längere Strecke ein gröberes Abtastintervall verwenden konnte, ohne dass das resultierende Diagramm für einen Läufer, der kurz darauf schaut, merklich anders aussah. Da bei einer Bulk-Anfrage für Höhen jeder Punkt als ein abgerechneter Eintrag zählt, stimmte das Entwicklungsteam der App das Abtastintervall gezielt auf die Streckenlänge ab, um nicht weit mehr Punkte anzufragen, als die visuelle Auflösung des resultierenden Diagramms tatsächlich brauchte.
Die App fügte auf Basis derselben Daten noch eine kleine Funktion hinzu: ein Abzeichen für die „Anstiegsschwierigkeit“ bei gespeicherten Strecken, berechnet aus dem gesamten Höhengewinn im Verhältnis zur Entfernung. So konnten Läufer zwei Strecken ähnlicher Länge schnell vergleichen, ohne für jede ein vollständiges Diagramm zu lesen, im Grundgedanken ähnlich wie eine Wander-App dieselbe zugrunde liegende Berechnung für die Schwierigkeit von Wegen nutzen könnte, nur abgestimmt auf die kürzeren Entfernungen und anderen Tempoerwartungen eines typischen Laufs statt einer Wanderung.
Die Nutzung gespeicherter Strecken nahm nach dem Start der Funktion zu. Das Team der App führte das gezielt darauf zurück, dass Läufer sich sicherer fühlten, eine unbekannte Strecke anzugehen, sobald sie sehen konnten, auf wie viel Anstieg sie sich tatsächlich einließen, statt die Schwierigkeit einer Strecke erst mittendrin beim ersten Lauf zu entdecken.
Höhenabfragen liefen einmal pro gespeicherter Strecke statt pro Lauf, da sich das Höhenprofil einer Strecke zwischen verschiedenen Läufen nicht ändert. Dadurch blieb das gesamte Anfragevolumen proportional zur Zahl der unterschiedlichen Strecken, die Nutzer anlegten, statt zur gesamten App-Nutzung, und für eine App mit einer moderaten Zahl aktiver Nutzer bequem innerhalb des kostenlosen Tageskontingents.
Die Dokumentation zum Endpunkt, einschließlich der Punktgrenzen pro Anfrage, finden Sie unter /docs/elevation-lookup/.