在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
估算路线的总爬升高度
总爬升是一个单一的数字，它能告诉徒步者或骑行者的路线难度信息，是仅凭距离永远无法提供的。而且一旦您拥有了路线上足够多点的海拔数据，计算它就很简单。
获取路线的海拔
按顺序把路线的坐标发送到 /v1/elevation，可以使用 points 参数，也可以作为批量 POST 数组发送。
GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750|45.8300,6.8800{
"status": "ok",
"results": [
{"lat": 45.8326, "lon": 6.8652, "elevation_m": 1035},
{"lat": 45.8400, "lon": 6.8700, "elevation_m": 1210},
{"lat": 45.8475, "lon": 6.8750, "elevation_m": 1390},
{"lat": 45.8300, "lon": 6.8800, "elevation_m": 1180}
]
}累加爬升
按顺序遍历结果，对每一对相邻的点，只有当海拔升高时才把差值加到累计总数中。在这个例子中，从 1035 到 1210 增加 175，从 1210 到 1390 增加 180，而从 1390 到 1180 不增加任何值，因为这一段是下坡。这一小段的总爬升为 355 米。
gain = 0
for i in 1..n:
diff = elevation[i] - elevation[i-1]
if diff > 0: gain += diff用同一份数据计算下降
用同样的循环，把比较条件反过来，就能得到总下降。对于终点低于起点的路线，例如从山上一路骑下来的点到点骑行，下降与爬升同样重要。
loss = 0
for i in 1..n:
diff = elevation[i] - elevation[i-1]
if diff < 0: loss += -diff对于上面的四个点，总下降为 210 米，全部来自最后一段下坡。对于任何不是简单往返的路线，只报告爬升而不报告下降的路线摘要只讲了一半的情况。
采样点间距会改变结果
总爬升对采样点的数量很敏感。点太少会把真实的上坡和下坡抹平，得出偏低的总数。在有噪声的 GPS 轨迹上取点太多，则可能因为微小的上下抖动而夸大数字，而这些抖动从来都不是真正的爬升。沿徒步轨迹每隔十到三十米取一个点，或重新采样为等距间隔，是一个合理的起点。
值得避免的错误
不先重新采样就直接在原始 GPS 轨迹上计算爬升，是得出夸大数字的常见原因，因为即使在真正平坦的地面上，消费级 GPS 轨迹在相邻记录点之间也经常上下抖动几米。请先把轨迹重新采样为等距间隔，再为其请求海拔，而不是为设备记录的每个原始点都请求海拔。
请求成本
每个点计为一次请求，无论是通过 points 参数还是批量数组发送。一条有 300 个采样点的路线消耗 300 次请求，这仍然只占每个密钥附带的每天 2,500 次免费请求中的一小部分。
用这种方法计算出的总爬升，其质量取决于背后的采样点选取，因此在确定间距之前，值得用一条已知路线测试几种不同的间距选择。完整的请求选项请参阅海拔查询文档页面。