永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么海拔数据总被当作事后才考虑的东西
在这个行业里，海拔数据面临的更多是形象问题，而不是技术问题。它被定位为锦上添花，是添加到地图视图或飞行规划工具上的点缀，而不是真正实用的应用所依赖的数据：洪水风险评估、排水规划、农业作业、航空净空计算、建筑工地评估。这些都不是小众用途。它们都需要像对待坐标或地址一样认真对待地面海拔，而不是把它当作硬加在地图产品上的装饰性附加项。
我们把海拔构建为一个真正的端点，在产品中拥有自己的位置，而不是埋在地理编码响应中、大多数集成根本不会注意到其存在的某个冷僻可选字段。它的定价与其他所有功能相同：包含在每天免费额度内，超出部分同样按每次请求 €0.0001 计费，或者包含在同一个 €50 的 Unlimited 密钥中，与地理编码、IP 和时区查询完全一样。它没有单独的更高价格，不会暗示它被视为一项特殊功能而不是标准功能。
海拔被低估的部分原因在于，在典型的面向消费者的产品中，它确实不如地址或地图上的图钉那样显眼。没有人会像注意到配送表单上的错误地址那样直接注意到海拔数据。但对最终用户不可见，并不会让底层数据对依赖它的系统变得不那么重要。一项排水计算如果因为输入的海拔数值有误而出错，并不会像错误地址那样暴露出来。它会在之后作为现实世界的后果，出现在某个假定地面高度正确的决策中。
我们把海拔视为产品中完全可用、可以具体描述的部分之一，与 IP 和时区数据并列，正是因为我们认为它应当获得与其他任何核心端点同等的信心和投入，而不是一句含糊其辞的保留或一条脚注。对于希望在已经进行的位置查询中同时获得地面海拔的调用者，它还可以作为可选附加项叠加到标准响应中，而无需为了使用它而另购一款特殊产品或另签一份合同。
更广泛的观点是，当一个产品把对最终用户的可见度当作实际重要性的替代指标时，海拔恰恰是会因此受害的那类数据。在农业、工程和风险评估领域，位置数据的一些影响最为深远的用途，完全依赖于最终产品的用户永远不会直接看到的数据。把这些数据做好，并把它定价为标准功能而不是特殊附加项，是在押注系统中不可见的部分应当获得与可见部分同样的关注，因为建立在它们之上的决策同样真实。