Anwendungsfälle

Ein Höhenprofil für eine Fahrrad-App erstellen

Radfahrer, die eine Route planen, interessiert eine Zahl mehr als jede andere: wie viele Höhenmeter anfallen. Vierzig flache Meilen und vierzig hügelige Meilen sind völlig unterschiedliche Touren, und eine Fahrrad-App für die Routenplanung brauchte eine Möglichkeit, diesen Unterschied zu zeigen, bevor sich jemand auf eine Tour festlegt, und nicht erst, wenn er drei Hügel hinter sich hat und es bereut.

Die App hatte Routen bereits als Abfolge von Koordinaten, die ihre eigene Routing-Engine aus einem Start- und einem Endpunkt erzeugte. Was fehlte, war die Höhe an jedem dieser Punkte. /v1/elevation löste das direkt: Man sendet eine Liste von Koordinaten, ob einen einzelnen Punkt oder eine lange Abfolge entlang einer Route, und erhält für jeden die Geländehöhe zurück. Eine Route mit zweihundert Punkten entlang ihrer Länge kam als zweihundert Höhenwerte zurück, weiterhin in der Reihenfolge, in der sie gesendet wurden, bereit, als Profil über der zurückgelegten Strecke dargestellt zu werden.

Diese Liste, aufgetragen über der kumulierten Strecke, ist das Steigungsdiagramm, das Radfahrer tatsächlich sehen wollen: wo die Hügel liegen, wie steil der Anstieg im Vergleich zu benachbarten Punkten aussieht und wo die flachen Abschnitte sind. Die App berechnete daraus den gesamten Höhengewinn einer Route, eine einzelne Zahl, die für Radfahrer bei der Entscheidung, ob sie eine Route in Angriff nehmen, wichtiger war als die Gesamtstrecke.

Da eine Route je nach Länge zwischen einigen Dutzend und einigen Hundert Punkten haben konnte und eine Sammel-Höhenanfrage jeden Punkt als ein abgerechnetes Element zählt, passte die App an, wie viele Punkte sie pro Route abtastete, statt für jede Tour die Höhe in der feinstmöglichen Auflösung anzufordern. Eine sanfte Route, die alle paar hundert Meter abgetastet wurde, ergab ein ebenso nützliches Profil wie eine, die alle zehn Meter abgetastet wurde, bei einem Bruchteil des Anfragevolumens, und für einen Radfahrer, der das resultierende Diagramm betrachtete, war der Unterschied unsichtbar.

Die App ermöglichte es einem Radfahrer außerdem, bei Bedarf einen einzelnen Punkt zu prüfen, indem er irgendwo auf die Karte tippte, um die Höhe genau an dieser Stelle zu sehen, wofür derselbe Endpunkt mit einer Ein-Punkt-Anfrage statt einer ganzen Route verwendet wurde. Sowohl der Einzelpunkt- als auch der Batch-Fall laufen über denselben Aufruf, was den Code der App einfach hielt: eine Funktion, die eine Liste von Koordinaten annimmt und eine passende Liste von Höhen zurückgibt, genutzt sowohl für ein kurzes Tippen als auch für eine vollständige Routenplanung.

Der Traffic wuchs mit der Zahl der Routen, die Radfahrer planten, und nicht mit der Zahl der Touren, die sie tatsächlich fuhren, da das Profil einer gespeicherten Route nur einmal berechnet werden musste. Für eine App mit einer aktiven, aber nicht riesigen Nutzerbasis blieben die Höhenabfragen so deutlich innerhalb des kostenlosen Tageskontingents, mit Prepaid-Guthaben als naheliegendem nächsten Schritt, falls eine beliebte neue Funktion einen Anstieg bei der Routenplanung auslöste.

Die Höhe ist einer der wenigen Endpunkte, für den sich leicht ein echtes Beispiel geben lässt: Eine Küstentour zeigt für ihre ersten Punkte Höhenwerte nahe dem Meeresspiegel und steigende Werte, sobald die Route ins Landesinnere ansteigt, ein Diagramm, das einem Radfahrer auf einen Blick etwas sagt. Details zum Anfrageformat und zu den Punktlimits finden Sie unter /docs/elevation-lookup/.