在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
为徒步或骑行路线构建海拔剖面图
海拔剖面图其实就是一串各自附带高度的点，按沿路线的距离绘制出来。海拔端点会在一次调用中为您发送的所有点返回高度。
发送路线
通过 points 参数传入一系列纬度和经度坐标对，坐标对之间用竖线分隔，每对内部用逗号分隔。
GET /v1/elevation?points=45.8326,6.8652|45.8400,6.8700|45.8475,6.8750{
"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}
]
}把结果转换为剖面图
results 中的每一项都与您在相同位置发送的点一一对应。把 elevation_m 与相邻点之间的累计距离（由您自己根据坐标计算）配对，就得到了剖面图的 x 值和 y 值，无需任何额外查询。
使用批量请求体的简短示例
如果您更愿意发送结构化数组，而不是用竖线分隔的 points 参数，可以像其他端点接受批量请求体那样，向 /v1/elevation POST 一个由坐标对象组成的 JSON 数组。
POST /v1/elevation
Content-Type: application/json
[{"lat": 45.8326, "lon": 6.8652}, {"lat": 45.8400, "lon": 6.8700}]无论哪种方式，费用都一样，每个点一次请求，因此请根据您现有的数据结构，选择更容易构建的形式：由数组构建的查询字符串，或以同样方式构建的 JSON 数组。
选择点的间距
一条每隔几米就有一个 GPS 点、共有上百个点的路线，并不需要每个点都有海拔数据才能画出清晰的剖面图。在长路线上每隔二十或五十个点取样一次，或按均匀的距离间隔重新取样，既能让图表保持平滑，又能减少请求数，因为 points 参数中的每个点都算作一次请求。
值得避免的错误
把 elevation_m 当作精确到厘米，是对数据提出了超出海拔剖面图所需的要求。这个值的精度足以绘制平滑、清晰的剖面图，并计算出合理的总爬升，但平地上相距一米的两个点可能返回略有不同的读数，这并不代表实际地形有任何变化。请让您的图表和爬升计算能够容忍这类细小的噪声，而不要把每一次波动都当作路线的真实特征。
边缘情况：水面或未测绘地形
落在开阔水面上或海拔数据稀少地区的点，可能会返回一个很低或平坦的值，而不是错误。如果您的路线包含轮渡或穿越偏远地形的路段，请对照地图本身检查剖面图中异常平坦的路段，而不要假设这个数字总是描述坚实的地面。
成本是多少
一个一百个点的剖面图就是一百次请求，完全在每个密钥附带的、或单个地址在没有密钥时可用的每天 2,500 次免费请求之内。每天为大量用户服务的路线规划工具仍应关注配额响应头，因为热门路线的海拔剖面图累积起来比单次查询快得多。
海拔数据把一张平面地图变成徒步者或骑行者真正可以据此规划的东西。完整的参数列表请参阅海拔查询文档页面。