将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
自托管 Nominatim 与使用托管的兼容替换服务的对比
自托管 Nominatim 是一条正当且文档完善的路径，很多组织都成功地运行着它，尤其是那些有充分理由把地理编码基础设施完全留在自己网络内的组织。但其中的取舍是真实存在的，值得直白地说清楚而不是一笔带过：您需要负责下载并导入 OpenStreetMap 数据提取包，配置足够的磁盘空间和内存以便以可接受的速度响应查询，随着 OpenStreetMap 本身的更新让这些数据保持合理的时效，并按照您的应用所需的可用性保证来运维服务器。
这些工作并不难在晦涩或缺乏文档上。难就难在它们是持续性的。一个在上线当天运行良好的自托管 Nominatim 实例，如果没有人安排更新流程，一年后其数据的时效性就可能下降；而要诊断某个特定地址为何不再正确匹配，需要同时了解 Nominatim 软件和底层 OpenStreetMap 的数据约定。
托管的兼容替换方案完全免去了这一运维层，代价是您的地理编码流量要经过第三方的基础设施，而不是您自己的。这才是这里真正要做的决定，而不是哪个选项单纯更好的问题。
My Geocode 的 Nominatim 兼容主机完全复现了自托管或公共 Nominatim 实例返回的响应结构：display_name、以字符串形式返回的 lat 和 lon，以及使用 OpenStreetMap 自身字段命名（如 suburb 和 postcode）的 address 对象，只有版权、条款和隐私文字有所不同。参考详情请见 /compatibility/nominatim/。针对自托管实例编写的代码应该只需更改主机和身份验证方式，因为字段结构保持不变。
在选择任何一条路径之前，值得诚实回答以下几个问题：
- 您的组织是否有某项具体的合规或数据驻留要求，只有自托管能满足而托管服务无法满足
- 目前维护自托管实例花费了多少工程时间，如果把这些时间用在其他地方，价值又是多少
- 您的流量是否高且稳定到足以证明基础设施成本是合理的，还是波动较大，更适合用可预测的按请求计费或订阅费用来处理
如果答案倾向于放弃自托管基础设施，托管端的身份验证使用通过 X-API-Key、Authorization: Bearer、HTTP Basic 认证或查询参数发送的密钥，取代公共 Nominatim 实例要求的基于 User-Agent 的使用政策。价格方面：无需密钥每天可免费请求 2,500 次，每个密钥每天再额外免费 2,500 次（按网络计算），之后使用预付额度，每次请求 €0.0001，或者选择每月 €50 的 Unlimited 密钥，与平台上所有其他端点的费率相同。对许多团队来说，把服务器成本、工程维护时间和请求量与这一价格对照计算一下，是无论结论如何都最快解决这个问题的方法。