Die Entfernung allein ist ein schlechter Maßstab dafür, wie schwer eine Wanderung tatsächlich ist. Ein flacher Weg von sechs Meilen entlang eines Flussufers und ein Weg von sechs Meilen, der einen Berg hinaufführt, erschienen im Verzeichnis einer Wanderführer-App beide unter derselben Bezeichnung „mittel, sechs Meilen“. Diese Einordnung hatte einen stetigen Strom von Beschwerden von Wanderern ausgelöst, die der Bewertung „mittel“ vertrauten und sich dann auf einem viel härteren Aufstieg wiederfanden, als sie erwartet hatten.
Die App speicherte jeden Weg bereits als Folge von Koordinaten, die seinen Verlauf nachzeichneten, gesammelt aus GPS-Aufzeichnungen, die Nutzer beigesteuert hatten. Was fehlte, war die Höhe entlang dieses Verlaufs, also genau die Angabe, die einen flachen Spaziergang von einem ernsthaften Aufstieg gleicher Länge unterscheidet. /v1/elevation nahm die vollständige Koordinatenliste eines Weges entgegen, da eine Bulk-Anfrage eine Liste von Punkten akzeptiert und für jeden eine Höhe zurückgibt, und die App erhielt für jeden Punkt entlang des aufgezeichneten Verlaufs einen Höhenwert, in derselben Reihenfolge, in der die Punkte gesendet worden waren.
Aus dieser Liste den gesamten Höhengewinn zu berechnen, also die Summe aller Anstiege entlang der Route, war einfache Arithmetik, die das eigene Backend der App erledigte. Der Gesamtanstieg ergab zusammen mit der Entfernung ein deutlich nützlicheres Schwierigkeitssignal als die Entfernung allein: Ein Weg mit viel Anstieg auf kurzer Strecke wurde als steil und schwierig eingestuft, egal wie kurz er auf dem Papier wirkte, während ein langer, flacher Weg trotz seiner Länge als leichter galt. Das entsprach dem, was Wanderer vor Ort tatsächlich erleben, weit besser als das alte System, das nur die Entfernung berücksichtigte.
Die App baute ihre Schwierigkeitsbewertung um diesen kombinierten Wert herum neu auf und berechnete jeden bereits im Verzeichnis vorhandenen Weg rückwirkend neu, ein einmaliger Stapelauftrag über die gesamte Wegbibliothek. Dieser Stapel war die größte einzelne Anfrage, die die App je gesendet hat. Da bei einer Bulk-Anfrage für Höhen jeder Punkt als ein abgerechneter Eintrag zählt und nicht jeder Weg, richtete sich die genaue Größe des Auftrags danach, wie viele Koordinatenpunkte es in der gesamten Bibliothek gab, und nicht nach der Zahl der Wege. Das Team berücksichtigte das bei der Kostenschätzung im Voraus, statt hinterher davon überrascht zu werden.
Über die zentrale Schwierigkeitsbewertung hinaus ermöglichten dieselben Höhendaten der App, auf jeder Wegseite ein Höhenprofil-Diagramm anzuzeigen, ähnlich wie es eine Radfahr-App zeigen würde. So sah ein Wanderer genau, wo entlang der Route die steilen Abschnitte lagen, statt nur eine zusammenfassende Schwierigkeitsbezeichnung zu kennen. Wanderer, die sich auf einen bestimmten anstrengenden Abschnitt vorbereiten wollten, statt nur zu wissen, dass ein Weg insgesamt schwer war, fanden das Diagramm nützlicher als die Bezeichnung allein.
Die laufenden Höhenabfragen nach dem ersten Stapel ergaben sich aus neu eingereichten Wegen, ein viel kleineres und gleichmäßigeres Volumen als das einmalige Neuberechnungsprojekt und bei der üblichen Rate neuer Einreichungen bequem innerhalb des kostenlosen Tageskontingents.
Ein Bewertungssystem ist nur so gut wie die Daten, auf denen es beruht, und die Höhe erwies sich als die fehlende Eingabe, die die Schwierigkeitsbewertung der App von Anfang an gebraucht hatte. Die Dokumentation zum Endpunkt, einschließlich der Grenzen für Punkte pro Anfrage, finden Sie unter /docs/elevation-lookup/.