本月上线内容：地理编码、IP、时区等
API 近期工作汇总：新的兼容主机、更快的时区和海拔查询、控制台新功能，以及更清晰的配额可见性。
更快的海拔端点，适用于长路线
徒步路线或驾车路线的海拔剖面很少只有一个坐标。它由路径上的几十个、有时几百个点组成，每个点都需要一个海拔数值，用来绘制爬升图或估算沿途的体力消耗。这种使用模式，即为一条连续路线请求大量坐标，正是我们最近对 /v1/elevation 进行优化时的重点。
该端点的请求和响应结构没有变化，/docs/elevation-lookup/ 中记载的所有内容仍然完全适用。变化的是内部处理路线上大批坐标的效率，目的是缩短获取一条长路径海拔剖面的时间，而不是单个孤立点。
由于批量请求一如既往地将每个坐标计为一项，这项改进影响的是速度，而不是价格或配额行为。一条包含两百个坐标点的路线，仍然按两百次请求计入适用的配额，无论是每日免费配额、按每次请求 €0.0001 计费的预付额度，还是 Unlimited 套餐的覆盖范围。变化的是响应返回所需的时间，这对于以交互方式而非后台任务生成路线剖面的应用有直接影响。
同样的改进也延续到了我们位于 /compatibility/open-elevation/ 的 Open-Elevation 兼容主机，因为它使用的是同一个底层海拔端点。任何已经通过该主机发送路线长度批量请求的应用，都能享受更快的处理速度，集成方无需做任何修改。
路线规划和徒步类应用往往最能直接感受到这类改进，因为如果海拔剖面的加载时间明显长于路线本身，等待地图的用户就会看到明显的延迟。对这类较长的、路线形态的批量请求加快响应，就能消除这种差距。
如果您的应用需要为由大量坐标组成的路线请求海拔，无论是徒步、骑行还是驾车导航，您应该会注意到完整剖面的返回速度悄然提升，而集成的其他方面都无需改动。完整的端点文档仍在 /docs/elevation-lookup/。